Beginner's Guide
Gate Post
Live Stream
Chat
Future Events
News
Gate Blog
Home
Recommend
Hot
Insight
Post

Cancun yükseltmelerinin geçmişi, bugünü ve geleceği

金色财经_vip

Geçmiş yaşam

**Cancun yükseltmesi neden gereklidir? **

  • 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 TPS ve performans düşük, gas ücreti yüksek ve sıkışıklık ciddi.Aynı zamanda Ethereum client çalıştırmak için gerekli disk alanı da hızla artıyor. Ethereum'un güvenliği ve ademi merkeziyetçiliği Hacim konsensüs algoritmasının tüm ortam üzerindeki etkisi de 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 mutabakat 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 çok blok oluşturmasını ve ölçeklenebilirliğini geliştirmesini sağlar.
  • Her Ethereum bloğunun mevcut 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'un TPS'sinin üst sınırı yaklaşık 100 ile sınırlıdır. Bu veriler açıkça Ethereum'un ihtiyaçlarını karşılayamaz.
  • Bu nedenle, Ethereum Layer 2, büyük miktarda verinin bloğa nasıl yerleştirileceğine odaklanır. Uzayda güvenlik, dolandırıcılık kanıtları ve geçerlilik kanıtlarıyla garanti edilir, bu nedenle DA katmanı, aynı zamanda Cancun yükseltmesinin temel içeriği olan güvenliğin üst sınırını belirler.
  • 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ı oluşturabilir, bu nedenle Cancun, TPS, gas çözmek için yükseltir. Ücretler ve geliştirici deneyimi, Ethereum yol haritası için kritik öneme sahiptir.

**Ethereum yol haritası nasıl planlanıyor? **

Son birkaç önemli yükseltme ve hedefleri

  • 2020yıl12ay1* İşaret zinciri resmi olarak yayınlandı ve POS yükseltmesinin* önünü açtı
  • 2021**8ay5** Londra yükseltmesi, EIP1559 Ethereum'un ekonomik modelini değiştirir;
  • 2022yıl9ay15* Paris yükseltmesi (** Birleştir**), tamamlanmış POW anahtarlama POS;*
  • 2023yıl4ay12* Şangay'da yükseltildi, rehin geri çekme sorununu çözdü;*
  • 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ına odaklanmaktır * Kabarmak* .
  • Hedef: Toplamada 100.000'den fazla TPS elde edin.
  • Zincir içi ve zincir dışı 2 şema vardır:
  • Zincir dışı çözüm: toplama vb. dahil olmak üzere Layer2'yi ifade eder.
  • On-chain şeması: popüler bir parçalama ş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çalama ş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ında senkronizasyon bir sorundur. Şu anda, büyük ölçekli bir ağ düğümü veri senkronizasyonunu tamamlamak zordur. MEV durumunu çözememekle birlikte ortaya çıkabilecek ve kısa vadede gerçekleştirilemeyecek çeşitli sorunları telafi etmek için çok sayıda yama gerektirebilir.
  • Danksharding, Ethereum için önerilen yeni bir parçalama tasarımıdır, Ana fikri Merkezi blok üretimi + Merkezi olmayan doğrulama + Sansüre karşı dirençBu aynı zamanda Örnekleme (DAS) altında belirtilen veri mevcudiyeti ile de ilgilidir. Blok Üretici-Paketleyici Ayrımı (PBS) ve Sansür Direnç Listesi (Crlist). Danksharding'in temel fikrinin en büyük önemi, Ethereum L1'i birleşik bir çözüme (yerleşim) ve veri kullanılabilirliğine (Veri kullanılabilirliği) dönüştürmekte yatmaktadır. Kullanılabilirlik)

Parçalama şeması 2 adımlara bölünmüştür, şu anda Proto- parçalama veTam Toplama*****. ***

  • Öyleyse- danksharding**:**
  • tanıtmak: Lekeleri tanıtarak L2 ücretinin düşürülmesine ve iş hacminin artırılmasına yardımcı olun , aynı zamanda tam parçalamanın önünü açmak için parçalama öncesi bir çözüm olarak. Proto-danksharding'den sonra danksharding'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ü sunmaktı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 verebilir, bu da büyük ölçüde ana zincir üzerindeki yükü hafifletir.Depolama baskısı ayrıca toplama maliyetini de azaltabilir.
  • Tam Toplama
  • Giriş: Toplama, veri kullanılabilirliğinin kullanımına odaklanarak tamamen genişletildi.
  • içerik:
  • DAS'ın P2P tasarımı: veri parçalama ağ bağlantısı sorunlarını içeren 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. kötü niyetli doğrulayıcı saldırıları veya büyük blok düğümlerinin uzun süreli kapalı kalma süresi) tüm verileri verimli bir şekilde yeniden oluşturma yeteneği.

Ethereum Çekirdek Geliştiriciler 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ıştığı ve Ethereum üzerinde gelecekteki çalışmaları koordine ettiğ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.
  • Temel 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 bu konferansa dahil olup olmadığına bakmaksızın bunu test eder. Yükseltme yapıp yapmama ve 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.
  • Konferanslar, iki haftada bir dönüşümlü olarak gerçekleştirilen mutabakat katmanı toplantısı ve yönetici katmanı toplantısı olmak üzere 2 kategoriye ayrılmıştır:
  • ** Uzlaşma katmanı toplantısı (Tümü Core Developers Consensus - ACDC), Ethereum konsensüs katmanına odaklanan (proof of stake, beacon chain, vb.);**
  • Yönetici düzeyinde toplantı ( Tümü Temel Geliştiriciler çözümü - Ethereum'un yürütme katmanına (EVM, Gas program, vb.) odaklanan ACDE.
  • 3 tür Ethereum temel koruyucusu vardır, çoğunlukla resmi kuruluşlar veya teklifleri tartışan gönüllü forumlar:
  • AllCoreDevs: ETH1 ağ istemcisinden sorumlu kod koruyucular, 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; *Ethereum Sihirbazlar: EIP ve diğer teknik konular etrafında tartışmalar isteyen bir "forum".

Cancun Yükselişle İlgili Toplantıların Zaman Çizelgesi

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

Aşama 1 - Yükseltme Temalarına Giriş

Yeni görevler tanıtınproto-danksharding***,EOF ve "selfdestruct" * İşlem kodu, Şangay yükseltme içeriğinin yüzeysel tartışması*

  • 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ında proto-danksharding, EOF ve "selfdestruct" opcode'un ilk kez uygulanması önerildi. Şu anda proto-danksharding'in özel kapsamı belirlenmedi, ve bazı geliştiriciler ön hazırlık aşamasındadır. Şangay yükseltmesinin, önce taahhüt edilen ETH çekimlerini etkinleştirmek ve ardından EIP'yi yükseltmek gibi birkaç küçük yükseltmeye bölünebileceğine inanılıyor. 4844, ancak başka bir geliştirici grubu, tek adımda daha büyük bir yükseltme uygulamanın daha mantıklı olduğunu düşünüyor.

2. Aşama - Zaman çerçevesinin belirlenmesi ve KZG törenine hazırlanma

2022** sonunda, Ethereum konferansı esas olarak **EOF ve EIP etrafında dönüyor 4844 Tartışma, EIP'yi tanıtmaya devam ederken 4844 ***—KZG töreni için gerekli ön-güvenilir ayar töreni, geliştiriciler *******23 tarihinde olacak **** Yıl **** 1 **** ay **** 4844 **** yükseltmesinin *** içinde görüneceği resmen onaylandı

  • 22 Kasım'da, Ethereum'un tüm temel geliştiricilerinin 149 numaralı konferans görüşmesinde EOF veya proto-danksharding'den bahsedildi.
  • 22 Aralık'ta yapılan mutabakat katmanı toplantısında, Ethereum ekosisteminin başkanı Trent Van Epps EIP'yi güncelledi 4844 Bir dosya oluşturmak için gerekli güvenilir kurulum töreninin uygulanmasında ilerleme 4844'te kullanılan güvenlik kodu. kamyonet Epps, törenin 8.000 ila 10.000 katkı toplayarak kripto alanındaki şimdiye kadarki en büyük törenlerden biri olacağını ve törenin kamu katkı döneminin yaklaşık 2 ay süreceğini ve Aralık ayında başlayacağını umuyor;
  • 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 Vakfı'nın bir geliştiricisi, EOF'nin Cancun'a ertelenmesine itiraz etti ve kod değişikliklerinin Şangay'a dahil edilmemesi durumunda, Kendini yok etme koduyla ilgili olarak Cancun'a girme olasılığı çok küçük, o sırada EIP'yi ilerletmeyi savunan geliştiriciler var. 4758, ancak bu işlem kodunu doğrudan devre dışı bırakmak bazı uygulamaları bozacaktır ve geliştirici, bu tür bir sözleşmeyi korumak için bir uç durum oluşturmadan önce bu EIP'nin bir süre yeniden tartılması gerektiğine inanır;
  • 9 Aralık 22'deki çekirdek geliştirici toplantısında, Cancun yükseltmesi ve mevcut EIP ile ilgili KZG töreninin uygulanması tanıtıldı. 4844 Gerekli güvenilir kurulum töreni hazır;
  • 16 Aralık 22'de EIP ile ilgili mutabakat katmanı toplantısında 4844'te, geliştiriciler iki farklı çekme isteğini (PR'ler) proto-danksharding'in spesifikasyonunda birleştirmeyi tartıştılar, biri veri ayıklamadan sonra belirli bir noktanın ötesinde düğümlerin veri kullanılabilirliğini nasıl ele aldığıyla ilgiliydi ve diğeri bir blok olduğunda Yeni hata kodları uyarı düğümlerine tanıtılacak. bloblar hakkında bilgi eksik
  • 5 Ocak 23'teki çekirdek geliştirici toplantısında geliştiriciler, EOF uygulamasıyla ilgili kod değişikliklerini Şanghay yükseltmesinden kaldırmak için bir fikir birliğine vardılar, Beiko şu anda iki hafta sonra EOF'nin Cancun'a yükseltilip yükseltilmeyeceğine karar vermeyi önerdi;

Aşama III - Teklifin kapsamının ön müzakeresi

231EOF sonunda promosyon için Cancun'a taşındı Şangay promosyonundan taşındıktan sonra , o zamandan beri 2 aylar, EOF** ve EIP dışında esas olarak etrafında dönmektedir 4844* dışındaki diğer öneriler tartışıldı ve aynı zamanda ***EOF'nin 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 teklif şuydu: EIP 4788 (genel işaret zinciri durum kökü), EIP 2537 (BLS imza doğrulaması ve SNARK doğrulaması gibi işlemleri verimli bir şekilde gerçekleştirin), EIP-5920 (yeni bir işlem kodu PAY tanıtılıyor) ve EIP 6189 (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ştirilmiş uygulaması;
  • 16 Mart 23'teki çekirdek geliştirici toplantısında, EOF ve EIP hariç 4844, aşağıdaki öneriler Cancun'a dahil edilmek üzere değerlendirildi: SSZ formatı, SELFDESTRUCT silme, EIP 2537,EVMMAX,EIP
  1. Sınırsız SWAP ve DUP talimatları, EVM'de PAY kodlarını ve işaret durumu köklerini tanıtan;
  • 30 Mart 23'teki çekirdek geliştirici toplantısında, EIP-6780'in SELFDESTRUCT'ı devre dışı bırakma önerisi ilk kez ortaya atıldı, bu aynı zamanda Cancun'un sonunda kullanmaya karar verdiği SEFDESTRUCT'ı devre dışı bırakma önerisidir. Ancak Erigon'dan EOF'nin uygulanmasıyla ilgili olarak (EL) Müşteri ekibindeki bir geliştirici EOF dedi Yaklaşan Cancún Yükseltmesinde Ethereum İyileştirme Önerisi EIP ile Rekabet Etmek İçin "Çok Fazla Değişiklik" 4844, Cancun yükseltmesinden kısa bir süre sonra EOF'yi hard forkta uygulamak için bir teklif vardı;

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

234 ayında, Cancun yükseltmesi tarafından kapsanması gereken teklifler için net bir yön var ve anahtar düğümler 4 ******************************************* *********************************************** *********** EIP ve tim de alternatif öneriler hakkında daha derinlemesine bir tartışma yaptı. 4ay 27,EIP tarihindeki toplantıda 6780、EIP 6475 veEIP 1153***'in Cancun'a dahil olduğu belirlenir ve aynı zamanda EOF ve EVMMAX ( ile) ***EOF ***uygulamayla ilgili EIP alt kümesi) Cancun yükseltmesinden kaldırıldı, EOF yükseltmesi esas olarak yardımcı oluyor EVM sürüm kontrolü gerçekleştirir ve aynı anda birden fazla sözleşme kuralı grubunu çalıştırabilir, bu da Ethereum'un müteakip genişlemesine yardımcı olacaktır, ancak tüm yükseltmenin fizibilitesini göz önünde bulundurarak, ** * EOFYükseltme, günlük yükseltme ile ileriye taşınabilir

  • 23****4ay12****, Ethereum Shanghai yükseltmesi tamamlandı;
  • 13.04.23 tarihindeki çekirdek geliştirici toplantısında, geliştiriciler EIP'yi tartıştı 4844 (EL'deki CL durum kökü hakkındaki verileri açığa çıkarmak için), yükseltme için düşünülen en az dokuz başka EIP vardır, yani EIP 4844**, SELFDESTRUCT KALDIR (EIP-6780, EIP 4758,EIP 6046,EIP 6190),EIP 5920,EIP 1153,EIP 2537,EIP 4788,EVMMAX EIP'ler（EIP 6601 ve EIP 6690), SS değişiklikler（EIP 6475, EIP 6493, EIP 6465, EIP 6404 ve EIP 6466 ）、EIP 5656 ve****EIP 6193**;
  • 27, 23 Nisan'daki çekirdek geliştirici toplantısında, çeşitli ilerlemeler ve ödünleşimler üzerinde duruldu. İlk olarak, EIP4844, aşağıdaki EIP'lerin eklenmesiyle Cancun yükseltmesine dahil edilmek üzere tanımlanmaya devam ediyor: EIP 6780 (SELFDESTRUCT işlem kodunun işlevselliğini değiştirir), EIP 6475 (isteğe bağlı değerleri temsil eden yeni bir Basit Serileştirme (SSZ) türü), EIP 1153 (çalışma durumuna yeni bir işlem kodu ekleyin); ikincisi, düşünülen ancak yükseltmeye resmi olarak dahil edilmeyen EIP EIP'dir. 6913 (SETCODE komutunun tanıtımı), EIP 6493 (SSZ kodlu işlemler için bir imza şeması tanımlayın), EIP 4788 (EL blok başlığındaki işaret zinciri blok kökünü açığa çıkarın), EIP 2537 (ön derleme olarak BLS12-381 eğrisini ekler) ve EIP 5656 (bellek bölgelerini kopyalamak için yeni EVM talimatları sunar); son olarak, EOF ** ve ** EVMMAX** (** EOF ** uygulamaya bağlı ** * EIP* alt küme) Cancun yükseltmesinden kaldırıldı. **EOF Yükseltme, ****2023****1**** başlangıcındaki Ethereum Geliştiricileri Konferansında Şanghay'ın dışına taşındı ve daha sonra 'dan yükseltildi *** 1'in sonundan 23***'de 4'ün başına kadar, varsayılan olarak Cancun yükseltmesinde görünecek, ancak ** 23** **EOF **29, 4 tarihindeki geliştirici toplantısında tekrar kaldırıldı. **

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

235ay esas olarak nihai teklifin ayrıntılarını kolaylaştırır ve geliştirir,SSZ-> RLP değişiklikleri, Cancun'daki ikiSSZ'ye artık ihtiyaç olmadığı anlamına gelecek EIP'ler**, yaniEIP'ler 6475 ve 6493, yükseltmeler için Cancun'dan taşınacak. Aynı zamanda, 26 gününde çekirdek toplantıda, Tim Beiko*, Cancun'un erişim alanını genişletmekle ilgili gelecekteki konuşmaların aşağıdaki beşEIP:EIP-5920 ile sınırlandırılmasını önerir. * ,5656,7069,4788 ve ****2530 * ****. Geliştiriciler artık Cancun yükseltmesinin tam kapsamını belirlediler. ***

*5/5/23 tarihli Ethereum Çekirdek Mutabakat toplantısı, bahsedilen son EIP'yi tartışıyor 4788, EIP eklerken 6987 ve EIP 6475'teki tartışma, bu iki teklif sırasıyla doğrulayıcılar ve SSZ işlemleri hakkındadır;

  • 11, 23 Mayıs'taki 161. Ethereum yönetici katmanı toplantısında Tim Beiko, Cancun yükseltmesinin kapsamının önümüzdeki birkaç hafta içinde hala değiştirilebileceğini, ancak geliştiricilerin açık tavsiyesi olmadan Cancun yükseltmesinin kapsamının "varsayılan" durumda kalacağını ve EIP-4844 hakkındaki tartışmanın gösterdiğini söyledi. Yazar, SSZ'yi EIP-4844'ün EL uygulamasından çıkarmayı kabul etti, **ancak bu, ** 6475 **'in devam eden ilerlemesini henüz etkilemedi. **Buna ek olarak, geliştiriciler Cancun'da değerlendirilmek üzere iki EIP'yi de kısaca tartıştılar: EIP 6969（EIP
  1. ve EIP 5656 (bellek bölgelerini kopyalamak için verimli EVM talimatları);
  • 4844'teki gelişmeler, EL üzerindeki 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 erişimini genişletmeye yönelik gelecekteki konuşmaların şu beş EIP ile sınırlandırılmasını tavsiye ediyor: EIP-5920**, 5656, 7069,* ** 4788* ** ve ** 2530**. Geliştiriciler önümüzdeki birkaç hafta içinde onaylayacak ** Dencun** (****Deneb
  • Cancun'un tüm yelpazesi****);**
  • 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 yola çıkarak araştırmacı, EIP 4844 özelliği, blok başına maksimum 4 blobtan 6'ya yükseldi. Aynı zamanda, geliştiriciler EIP'yi düşünüyor Cancun yükseltmesine dahil olan 4788;
  • 13 Haziran 2023'teki temel geliştirici toplantısında, geliştiriciler EIP dahil olmak üzere yükseltme kapsamını resmi olarak onayladılar 4844,EIP 1153,EIP 5656,EIP 6780,EIP 4788;
  • 15 Haziran 2023 tarihli mutabakat toplantısında, Deneb'e hangi CL merkezli EIP'lerin dahil edileceği tartışıldı, bunlara EIP-6988, EIP-7044, EIP-7045 eklenmesi önerildi ve CL müşteri ekibi kabul etti Bir EIP-4844 test ağı Devnet6, artan blob sayısını test edecek ve iki hafta içinde konu hakkında nihai bir karar verecek, Ethereum Vakfı araştırmacısı Michael ise Neuder, aktif doğrulayıcı setinin büyümesini azaltmaya yardımcı olmak için 32 ETH staking sınırının kaldırılmasını önerdi;
  • 22 Haziran 2023'teki toplantıda Tim, önceden derlenmiş 4844 adresinin 0xA'ya taşınmasını, paketlenmesini ve EIP aracılığıyla önceden derlenmiş olmasına rağmen BLS'nin başka bir adrese taşınmasını önerdi. 2537, ancak Cancun'da dikkate alınmayacak;
  • 29 Haziran 2023'teki fikir birliği toplantısında geliştiriciler, hedef blobu sınırlayarak blob sayısını tartışmaya devam etti. 2'den 3'e yükseltildi, maksimum blob limiti 4'ten 6'ya yükseltildi ve 4844 test ağı Devnet #7 yakında geliyor.

bu hayat

  • Temel içerik EIP'dir 4844, Proto-Dansharding
  • Bu Cancun yükseltmesi için son EIP aralığı: EIP 4844**,EIP 1153,EIP 5656,EIP 6780,EIP 4788. Bu arada, 19 Haziran'daki 111. Ethereum ACDC toplantısında geliştiriciler EIP'yi tartışmaya devam etti. 6988,** EIP 7044**,**EIP 7045 Deneb'e dahil edilmek üzere. Geliştiriciler, önümüzdeki haftalarda yukarıda bahsedilen üç EIP'yi Deneb spesifikasyonuyla birleştirmeyi planladıklarını söylediler.

AnahtarEIP****** analizi

EIP 4844

  • Giriiş:
  • EIP4844 teklifinin adı, parçalama genişletme Danksharding'in tam sürümünün ön protokolü olan Proto-Danksharding'dir. Parçalama şemalarının tamamı aslında zincir üstü genişletme için Toplama'ya dayanmaktadır. **Programın amacı ** 2 katmanını **Toplama——****L2'nin ücretleri düşürmesine ve verimi artırmasına yardımcı olarak genişletmektir , tam parçalamanın (parçalama) yolunu açarken. **
  • 23 Şubat konferans görüşmesinde, Ethereum geliştiricileri EIP yapacak 4844 yükseltmesi, gelecekteki ilgili GitHub sürümündeki EIP olan Cygnus takımyıldızındaki birinci büyüklükteki bir yıldızın adı olan Deneb olarak adlandırıldı. 4844'ün adı Deneb olarak güncellenecek, 1 Haziran 23'te yapılacak toplantıda CL tarafında Deneb, EL tarafında Cancun olarak adlandırılan Ethereum'un bir sonraki upgrade spesifikasyonunda bazı değişiklikler yapılacak;
  • 23 Haziran'daki geliştirici toplantısında, geliştiriciler EIP'yi güncellemeye hazırlandı 4844'ün önceden derlenmiş adresi. Şu anda çekirdek geliştiriciler, EVM'ye 9 ön derleme eklediler ve şu tarihe kadar EIP'yi etkinleştirecekler: 4844 ve 4788, sırasıyla "0xA" ve "0xB" adresleri altında iki ön derleme oluşturur. 29 Haziran'daki mutabakat toplantısında EIP lansmana hazır 4844'ün özel kısa süreli test ağı Devnet #7.
  • EIP-4844** yepyeni bir işlem türü sunuyor - Blob İşlem。** *Blob profili:
  • Blob, eklenti veri paketine benzer, başlangıçta yalnızca 128 KB'nin depolama alanı, teklifin görüşülmesinin başında Blob'un hedef ve limiti 2/4 iken, 9 Haziran 23'teki geliştirici toplantısında 3/6 olarak ayarlandı. Yani, şu anda Ethereum'daki her işlem en fazla üç Blob işlemi, yani 384 taşıyabilir. KB, her bloğun hedefi Blob kapasitesi 6, yani 768'dir. 2 MB olan 16 blob'a kadar taşıyabilen KB;
  • Ağ kararlılığı üzerinde belirli bir etkisi olabilir, ancak Ethereum geliştirme ekibi, blob bloğunu genişletmek için sonraki hard forklara duyulan ihtiyacı önlemek için yine de önce test etmeye karar verdi.
  • Blob **içinde ** KZG Hash işleme Veri doğrulama için kullanılan bir ** Hash olarak, işlev ** Merkle ; işlevine benzer
  • Düğüm, zincirdeki Blob'u senkronize eder İşlemden sonra, blob bölümünün süresi dolacak ve belirli bir süre sonra silinecektir ve depolama süresi üç haftadır.
  • Blob işlevi - Ethereum'un TPS'sini geliştirirken maliyetleri düşürürken
  • Şu anda, tüm Ethereum'un toplam veri hacmi yalnızca yaklaşık 1 TB'tır ve Blob, Ethereum'a her yıl 2,5-5 TB 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 bir ay boyunca sabit miktarda blob verisini yaklaşık 200~400 GB artırır. Ethereum düğümü, ancak Rollup etrafındaki genişleme büyük ölçüde geliştirildi;
  • Aslında, 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** rolü - Danksharding öyküsünün** ilk bölümünü açmak için
  • **Yüksek kapasite genişletme: **Ş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şleterek merkeziyetçilikten uzaklaştırma ve güvenlik sağlar. daha yüksek genişleme elde etmek;
  • **Düşük ücretler: **Bernstein analistleri, Proto-dank-sharding'in 2. katman ağının ücretlerini mevcut düzeyin 10-100 katına kadar azaltabileceğini gösteriyor;
  • 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 ifşa etmez;
  • Kesin olarak söylemek gerekirse, Celestia'nın Ethereum ile çok az ilgisi vardır 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, maliyeti 100~1000 kat azaltmayı beklemektedir, çünkü Danksharding ana ağının ayrıca Katman 1 P2P ağ yayını ile güvenliği ve uyumluluğu hesaba katması gerekir.
  • **DA****Çözüm: Danksharding (Ethereum'un genişletilmesi için bir parçalama çözümü) şu anda, genişleme devam ederse düğüm yükü çok büyük olabilir (****16mb) **** yukarıda) ve yetersiz veri mevcudiyeti (30 gün geçerlilik). Çözüm: **
  • Veri kullanılabilirliği örneklemesi (Veri Kullanılabilirlik Örneklemesi) - düğümler üzerindeki yükü azaltır
  • Blob'taki verileri veri parçalarına ayırın ve düğümün 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ı Ethereum defterinin tamamında saklanan öncül, düğümlerin yeterli ve merkezi olmayan olması gerektiğidir;
  • DAS iki teknoloji kullanır: silme kodu (Silme Kodlama) ve KZG Polinom Taahhüdü (KZG Bağlılık);
  • Teklif Veren-Paketleyici Ayrımı (PBS)——Düğümlerin işbölümü sorunu çözüldü, yüksek performanslı konfigürasyona sahip düğümler kodlama dağıtımı için tüm verileri indirmekten sorumlu olsun ve düşük performanslı konfigürasyona sahip düğümler sorumlu olsun yerinde kontrol doğrulaması.
  • Yüksek performanslı yapılandırmaya sahip bir düğüm oluşturucu olabilir. Oluşturucunun yalnızca kodlama için blob verilerini indirmesi ve bir blok (Blok) oluşturması ve ardından bunu nokta kontrolleri için diğer düğümlere yayınlaması gerekir. Oluşturucu için, çünkü senkronizasyon veri hacmi ve bant genişliği gereksinimleri yüksektir, dolayısıyla nispeten merkezi olacaktır;
  • Düşük performanslı yapılandırmaya sahip bir düğüm, bir teklif sahibi (Teklif Sahibi) olabilir ve teklif sahibinin yalnızca verilerin geçerliliğini doğrulaması ve blok başlığını (Blok başlığı) oluşturup yayınlaması gerekir. Başlık), ancak teklif sahibi (Teklif Sahibi) için senkronizasyon veri hacmi ve bant genişliği gereksinimleri düşüktür, bu nedenle merkezi olmayan olacaktır.
  • Anti-sansür listesi (crList) - aşırı inceleme güçleri nedeniyle paketleyicilerin belirli işlemleri kasıtlı olarak göz ardı edebilmeleri ve MEV elde etmek istedikleri işlemleri rastgele sıralayıp eklemeleri sorununu çözer.
  • Oluşturucu (Builder) 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 (İnşaatçı) yalnızca işlemleri crList'te paketlemeyi ve sıralamayı seçebilir; bu, oluşturucunun MEV'yi elde etmek için kendi özel işlemini ekleyemeyeceği veya bir işlemi kasten reddedemeyeceği anlamına gelir (Gaz limit dolu);
  • Paketlemeden sonra Oluşturucu, Karma işlem listesinin son sürümünü Teklif Sahibine yayınlar ve Teklif Sahibi, blok başlığını oluşturmak için işlem listelerinden birini seçer (Blok Başlık) ve yayın;
  • Düğüm verileri senkronize ettiğinde, blok Gövdesinin seçilen son 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 - MEV'yi alarak merkezi paketleyicilerin 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 (Kurucu) 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, paketleyici kasten blok Gövdesini vermezse, bloğun geçersiz olduğu kabul edilir. bulunmuyor).
  • Anlam:
  • Her şeyden önce, oluşturucunun (Builder) işlemleri paketlemek için daha fazla gücü vardır, ancak yukarıda bahsedilen crList, ilk olarak geçici olarak işlem ekleme olasılığını sınırlar ve ikinci olarak, oluşturucu (Builder) işlemlerin sırasını değiştirerek kar etmek istiyorsa, blok başı kalifikasyonunu alabilmesi için başlangıçta çok fazla teklif verme maliyeti ödemesi gerekir, ardından elde ettiği MEV karı daha da azalır ve genel olarak araçlar ve gerçek değer üzerinde bir etkisi olur. MEV elde etme;
  • Bununla birlikte, erken aşamada, yalnızca az sayıda insan paketleyici olabilir (düğüm performans sorunları göz önüne alındığında), çoğu kişi yalnızca teklif sahibi olabilir, bu da daha fazla merkezileşmeye yol açabilir. Aynı zamanda, paketleyici sayısı çok azdır durumunda, 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 fazla etkileyecektir;
  • MEV müzayedelerini kullanan bazı MEV çözümleri üzerinde bir miktar etkisi vardır.
  • Anlam:
  • EIP 4844 Aslında süper basitleştirilmiş bir sürüm Danksharding**: **Danksharding ile aynı uygulama arayüzünü sağlar, buna Data adlı yeni bir işlem kodu dahildir Hash; ve Binary adlı yeni bir veri nesnesi Büyük Nesneler yani Blob;
  • proto-danksharding ** tam ** Danksharding ** "braket" belirtimini** ** (** işlem formatı ve doğrulama kurallarıdır****) uygulamak için kullanılır * * Teklif: Ancak, henüz parçalama uygulanmadı ve tüm doğrulayıcılar ile kullanıcıların, eksiksiz verilerin kullanılabilirliğini doğrudan doğrulaması gerekiyor;
  • Uzun vadeli perspektif neden proto-danksharding'i değil EIP'yi seçer 4488 ** ** layer2 ** ücretini doğrudan azaltır, çünkü gelecekte tam bir shard'a yükseltirken yalnızca küçük bir ayarlama gerekir**: *EIP 4488 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;
  • Eksiksiz sharding elde etmek (veri kullanılabilirliği örneklemesi vb. ile) çok karmaşık bir görev olmasına ve proto-danksharding uygulandıktan sonra hala yapılacak çok iş olmasına rağmen, bu karmaşıklıklar fikir birliği katmanında kontrol edilecektir. Proto-danksharding devreye alındıktan sonra yürütme katmanı istemci ekibi, toplama geliştiricileri ve kullanıcıların tam parçalamaya geçiş için herhangi bir ek iş yapmaları gerekmez.
  • Tam parçalama elde etmek için ** PBS'nin gerçek uygulamasını, yetkilendirme kanıtını ve veri kullanılabilirliği örneklemesini tamamlamak gerekir, ancak bu tür değişiklikler ** CL *'de yoğunlaşacaktır. * katmanı, Geliştiricilerin yeniden ayarlama yapmasına gerek yoktur **: 4844 şu anda tam parçada gereken işlem biçimi, fikir birliği çapraz doğrulama mantığı ve yürütme katmanı mantığı ile tamamen aynı olan yeni bir işlem türü uygular ve ayrıca Bloblar için türetilmiş , kendi kendini ayarlayan bağımsız gaz fiyatlandırması, gelecekte tam parçalama elde etmek için, PBS'nin gerçek uygulamasını, yetkilendirme kanıtını ve veri kullanılabilirliği örneklemesini tamamlamak gerekir, ancak bu değişiklikler yalnızca CL katmanındadır ve Geliştirme için uygun olan EL katmanı veya toplama geliştiricilerinin değişiklik yapmasını gerektirmez By.

ardındanSELFDESTRUCT çıkarma***,EIP-6780 sonunda en uygun çözüm olarak belirlendi, ancak geliştirici 26** Meeting tim**, programatik hesapların güncellenmesine izin vermek için bu teklifeSETCODE başka bir işlem kodu eklenmesini önerdi***

KENDİNİ İMHA kaldırma EIP-6780**：**X

  • arka plan:
  • 21 Mart'ta Vitalik, SELDESTRUCT'ın 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 kodlarında değişikliklere neden olan tek kişi olması, ve hesabın izni olmadan kullanılabilir. Ethereum'un güvenliğinde büyük gizli tehlikeler barındıran hesap bakiyesinin işlem kodunu değiştirebilir;**
  • 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. selfdestruct** işlevi, geliştiricilerin acil bir durumda akıllı sözleşmeyi silmesine ve 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, 6780, 4758, 6046 ve 6190 olmak üzere SEFDESTRUCT ile ilgili dört teklif ve müteakip EIP tartışmaya katılmak üzere tanıtıldı. 6780 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. *EIP 6780: Sözleşmede aynı işlemde olmadıkça SEFDESTRUCT'ı devre dışı bırakın.
  • GÜNCELLEME: 26 Mayıs'ta tim, programatik 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 EIP emilimi 4758'in avantajları, dapp'a yükseltilmesi için alan sağlar.

  • Sebep: SELFDESTRUCT kodunun manipüle edilmesi, başlangıçta tüm kodların ve depolamanın silinmesi gibi hesap durumunda kapsamlı değişiklikler gerektirdi. Bu, gelecekte Verkle ağaçlarını kullanmak için bir zorluk teşkil ediyor: her hesap, açıkça kök hesaba bağlanmayacak birçok farklı hesap anahtarında saklanacak.
  • DEĞİŞTİRİLDİ: Bu EIP, aşağıdaki iki durum dışında SEFDESTRUCT'ı kaldırmak için değişiklikler uygular
  • Para çekmek için yalnızca SEFDDESTRUCT için kullanılan uygulamalar çalışmaya devam edecektir;
  • Sözleşmede aynı işlemde kullanılan SEFDESTRUCT'ın değiştirilmesine gerek yoktur.
  • Önem: Artırılmış güvenlik
  • Daha önce, ana ağ üzerinde, sözleşme yoluyla 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 önleyin, bu durumda bu kasa, tekrarlanan kullanım sırasında herkesin kasadaki belirteçleri çalmasına neden olabilir.

Aşağıdaki üç teklif, SELFDESTRUCT hakkında 23yıl*****4 *** tarihinde daha sonra silinen tekliflerdir. 6780 *28 tarihindeki çekirdek geliştirici toplantısında resmi olarak seçildi ve diğer üç tekliften vazgeçildi. Ethereum geliştirme ekibinin sonunda SELFDESTRUCT işlem kodunu tamamen silmek istemesi ve aşağıdaki üç teklifin çoğunlukla değiştirilerek değiştirilmesidir. ***

  • EIP-4758 (KALDIRILMIŞTIR): 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 kodunu manipüle etmek, tüm kodları ve depolamayı silmek gibi hesap durumunda kapsamlı değişiklikler gerektiriyordu. Bu, gelecekte Verkle ağaçlarını kullanmak için bir zorluk teşkil ediyor: her hesap, açıkça kök hesaba bağlanmayacak birçok farklı hesap anahtarında saklanacak.
  • Değiştirmek:
  • Opcode SEFDESTRUCT, SENDALL olarak yeniden adlandırıldı, artık yalnızca hesaptaki tüm ETH'yi arayana taşıyor, bu şema artık kodu ve depolamayı yok etmiyor veya rastgele sayıları değiştirmiyor;
  • SEFDESTRUCT ile ilgili tüm geri ödemeler silinmiştir.
  • Anlam:
  • EIP-6780 ile karşılaştırıldığında orijinal işlevsellik korunmuştur, çünkü bazı uygulamalar hala SEFDDESTRUCT kodunu kullanmaya/kullanmaya ihtiyaç duymaktadır.
  • EIP-6046 (KALDIRILMIŞTIR): 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ğacı ile hesaplar farklı şekilde düzenlenecektir: hesap özellikleri (depolama dahil) ayrı anahtarlara sahip olacaktır, ancak kullanılan tüm anahtarları bulmak ve 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ı değiştirin, böylece düzenli olmayan artış 2^64-1 yerine 2^64-2 ile sınırlandırılır;
  • SELFDESTRUCT şu şekilde değiştirildi:
  • Herhangi bir depolama anahtarını silmeyin ve hesabı yerinde bırakmayın;
  • Hesap bakiyesini ** hedefine aktarın, **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.
  • Anlam:
  • Bu teklif, SEFDESTRUCT'ın diğer doğrudan silinmesinden daha fazla esnekliğe sahiptir.
  • EIP-6190 (KALDIRILMIŞTIR): Verkle ile uyumlu SELFDESTRUCT, yalnızca sınırlı sayıda durum değişikliğine neden olacak şekilde değiştirildi
  • 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ĞİŞTİRİLDİ: Bir iş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 ayarlandı ve rastgele sayı 2^64-1 olarak ayarlandı.
  • Sözleşmenin 0. depolama alanı, CREATE işlem kodu ( keccak256(contractAddress, nonce)) adres verildiğinde verilecektir. 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 bakiyesi, yığının en üstündeki adrese tamamen aktarılacaktır;
  • Yığının üstü açılır.
  • Anlam:
  • SEFDESTRUCT'ın daha sonra en az değişiklikle Verkle ağaçlarını oluşturmasına izin verecek şekilde tasarlanmıştır;
  • Uygulanan EIP-2929 ile gaz maliyeti arttı.

ArdındanEIP 1153***,gaz tasarruf ederken, gelecekteki depolama tasarımının önünü açar***

EIP 1153X

  • Ö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.
  • yeniden giriş ile örnek olarak kilit, kilidin durumunu iletmek için ara çerçevelere güvenemez: SLOAD depolama SLOAD yoluyla SSTORE iletişimi pahalıdır ve geçici depolama, çerçeveler arası iletişim sorununa adanmış 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, sahibi olan sözleşmeye özeldir, tıpkı 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ş kilit;
  • Zincir üzerinde hesaplanabilir CREATE2 adresleri: yapıcı parametreleri, başlatma kodu karmasının bir parçası olarak geçmek yerine fabrika sözleşmesinden okunur;
  • Tek işlem EIP-20 onayı, örneğin #temporaryApprove(address harcayan, 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;
  • "Kana Kadar" modu: Kullanıcının geri aramanın bir parçası olarak tüm eylemleri gerçekleştirmesine izin verir ve sonunda "kadar"ın 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.
  • Anlam:
  • Tasarruf gaz**, daha basit** gaz faturalandırma kurallarıyla;
  • ** Çerçeveler arası iletişim sorununu çözün; **
  • ** Mevcut işlemlerin anlamını değiştirmeyin; **
  • Kullanımdan sonra depolama tankını temizlemeye gerek yoktur;
  • ** Gelecekteki depolama tasarımlarının (** Verkle ** ağaçları gibi) anlık depolama için geri ödemeleri dikkate almasına gerek yoktur. **

Ardından 4788, rehin havuzundaki güven varsayımını azaltabilir**

EIP 4788**:**X

  • Giriş: EVM'de işaret bloğu kökü. *Güncelleme: 15 Haziran 23'teki geliştirici toplantısında, geliştiriciler staker deneyimini iyileştirmek için kod değişiklikleri yapmayı teklif ettiler, bu EIP, DApp geliştirme için EVM dahili zincir durumu bilgilerini içeren beacon chain bloğunun kökünü ifşa edecek. yazarın güveni erişimi en aza indirir.
  • DEĞİŞTİRİLDİ: Her işaret zinciri bloğunun karma köklerini karşılık gelen yürütme yükü başlığında işleyin, 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, sözleşme katmanı (CL) durumunu açığa çıkarabilmesi için Ethereum Sanal Makinesini (EVM) değiştirmeyi öneren bir kod değiştirme önerisidir. yürütme katmanındaki (EL) kök Veriler, Ethereum ağındaki farklı protokoller ve uygulamalar arasındaki iletişimi daha verimli ve güvenli** yapabilir. **Stake havuzları, köprüleme ve yeniden paylaştırma protokolleri için daha güvenilir tasarımlara izin verin.

Sonuncusu5656***, verimli yeni bir bellek kopyalama işlem kodu sağlar, ancak test bant genişliği nedeniyle şu anda yükseltmeye geçici olarak dahil edilme durumundadır** *

EIP 5656X

  • Giriş: MCOPY
  • Bellek kopyalama talimatı. Güncelleme: 09.06.23, geliştirme ekibi başlangıçta MCOPY konusunda ikiye bölündüklerini, çünkü güvenlik sorununu çözse de yükseltme için gereken uygulama+test bant genişliğine onu ekleme konusunda hala endişeli olduklarını ancak sonunda şunları dahil etmeyi kabul ettiklerini belirtti: EIP , ancak geliştirici test sırasında veya istemci tarafında kapasite sorunlarıyla karşılaşırsa kaldırılması düşünülü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 kullanılabilirliğiyle, kod sözcükleri ve cümleler daha kesin bir şekilde kopyalanabilir, bu da bellek kopyalama performansını yaklaşık %10,5 oranında artırır, bu da çeşitli hesaplama yoğun işlemler için çok yararlıdır;
  • Derleyicilerin daha verimli ve daha küçük bayt kodu oluşturması da yararlı olacaktır;
  • Önceden derlenmiş gaz maliyetlerinden belirli bir miktar tasarruf sağlayabilir, ancak bu bölümün uygulanmasını fiilen teşvik edemez.

Kısa liste****EIP

236ay15** tarihinde, 'de tartışılan geliştirici mutabakat toplantısı EIP CL merkezli Deneb'e dahil edilmiştir, burada **** ** EIP 6988****、EIP 7044、******EIP 7045 *** *** katılması önerilir. ***

EIP 6988**:**X

  • Özet: Kesikli doğrulayıcıların blok teklifçileri olarak seçilmesini önleyin.
  • Önem: İhlal eden düğümler için artan cezalar, DVT'ye fayda sağlayacaktır.

EIP 7044**:**X

  • Özet: İmzalı doğrulayıcı çıkışlarının kalıcı olarak geçerli olmasını sağlamak.
  • Önem: Stake yapanların deneyimini bir dereceye kadar iyileştirebilir.

EIP 7045**:**X

  • Giriş: tasdik olacak Slot dahil etme aralığı, bir çağlık bir hareketli pencereden iki çağa kadar uzanır.
  • Önem: Ağ güvenliğini geliştirin.

EIP* analizini silin

29************************** **** gününde ******************************************* içinde ** 160****ACDE Ethereum toplantısı, EVMMAX ve **** EOF 'nin bu yükseltmeden kaldırılacağı onaylandı, EOF ile ilgili değişiklikler sonraki günlük yükseltmelerde sunulabilir

EVMMAX EIP'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. *EIP 6601: EVM Modüler Aritmetik Uzantılar (EVMMAX)
  • Değişiklik: EIP 5843 yineleme, EIP ile 5843'ün farkı:
  • 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 bite 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, EIP-6601 modüler aritmetik için bir kurulum bölümü, ayrı bir bellek alanı ve yeni işlem kodları sunarak bu temelde daha fazla yükseltme yapar İşlemler daha iyi organizasyon sağlar ve daha büyük modülü desteklerken ve EVM performansını geliştirirken esneklik.
  • Çeşitli eğriler üzerinde (BLS12-381 dahil) eliptik eğri aritmetik işlemleri sağlayan bir EVM sözleşmesi olarak;
  • MULMOD, 256 bit'e kadar olan değerlerdeki işlemlerin gaz maliyetini mevcut ADDMOD işlem kodlarına kıyasla %90-95 oranında azaltır;
  • Modexp ön derlemesinin bir EVM sözleşmesi olarak uygulanmasına izin verir;
  • Cebirsel hash fonksiyonlarında (örn. MiMC/Poseidon) ve EVM'de ZKP doğrulama maliyetini önemli ölçüde azaltır. *EIP 6690:
  • 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'ye bağımlılığı 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 basitleştirme, EIP-6601 avantajıyla ilişkili faydaları sağlamaya devam ederken daha verimli uygulama ve benimsemeye izin verir.

EOF değişiklikler**:**

  • 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 dizisidir (yapılandırılmamış talimat dizisi) bayt kodu. 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. *EIP 663:
  • Özet: Sınırsız SWAP ve DUP talimatları
  • Önem: Yığın derinliğini 16 öğeden 256 öğeye çıkararak SWAP ve DUP'tan ayrılan iki yeni talimat sunarak: SWAPN ve DUPN *EIP 3540:
  • Giriiş:
  • Geçmişte, zincire dağıtılan EVM bayt kodunun önceden tanımlanmış bir yapısı yoktu ve kod yalnızca istemcide çalıştırılmadan önce doğrulanıyordu.Bu sadece dolaylı bir maliyet değil, aynı zamanda geliştiricilerin yenilerini tanıtmasını da engelliyor. özellikler veya kullanımdan kaldırılmış eski özellikler.
  • Bu EIP, EVM için genişletilebilen ve sürüm kontrollü bir kapsayıcı sunar ve EOF sözleşmesinin biçimini bildirir. Buna dayanarak, EOF sözleşmesi dağıtılırken, yani oluşturulurken kod doğrulanabilir. Zaman doğrulama, EOF formatına uymayan sözleşmelerin dağıtılmasının engellenebileceği anlamına gelir. Bu değişiklik, mevcut EVM talimatlarını devre dışı bırakmaya veya gelecekte büyük ölçekli işlevleri (hesap soyutlama gibi) uygulamaya koymaya yardımcı olacak EOF sürüm kontrolünü uygular. .
  • Anlam:
  • 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, L2 doğrulayıcıların gas maliyetini düşürür.Aynı zamanda, sözleşme kodunun ve verilerin ayrılması, zincir üstü veri analizi çalışmaları için de daha uygundur. aletler. *EIP 3670:
  • Giriş: EIP-3540'a dayalı olarak amaç, EOF sözleşmesinin kodunun formata uygun ve geçerli olmasını sağlamaktır ve formata uymayan sözleşmelerin devreye alınması, Legacy'yi etkilemeden engellenecektir. bayt kodu.
  • Ö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. *EIP 4200:
  • Giriiş:
  • İlk EOF'ye özgü işlem kodlarını tanıttı: kodlayan RJUMP, RJUMPI ve RJUMPV imzalanmış anlık değerler olarak hedefler. Derleyiciler, jumpdest yapmak için mevcut JUMP ve JUMPI işlem kodlarına olan ihtiyacı ortadan kaldırdıkları için, JUMP'u dağıtırken ve yürütürken gaz maliyetini optimize etmek için bu yeni JUMP işlem kodlarını kullanabilirler. Analiz için gereken çalışma süresi. Bu EIP dinamik içindir Atlama eklenmesi.
  • Geleneksel JUMP işlemleriyle karşılaştırıldığında, fark, RJUMP gibi işlemlerin belirli bir ofset konumu belirtmemesi, ancak göreli bir ofset konumu belirtmesidir (dinamikten atlamalar -> statik atlamalar), çünkü birçok kez statik atlamalar yeterlidir.
  • Önem: ağı optimize edin ve maliyetleri azaltın. *EIP 4750:
  • 4200'ün işlevini bir adım öteye taşıyın: CALLF'u tanıtarak İki yeni işlem kodu ve RETF, RJUMP, RJUMPI ve RJUMPV ile değiştirilemeyen durum için alternatif bir çözüm uygular, böylece EOF sözleşmesinde JUMPDEST'e artık ihtiyaç duyulmaz, dolayısıyla dinamik yasaklanır zıplamak.
  • Önem: kodu birkaç parçaya bölerek kodu optimize edin. *EIP 5450:
  • Arka plan: Arka plan hala Ethereum sözleşmesinin dağıtı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), gazın yeterli olup olmadığı, ve benzeri.
  • İç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şmesi konuşlandırmasının yığının taşmasına veya taşmasına neden olabileceği durumları önler (yığın taşmalar/taşmalar). 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: 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 yapmak büyük bir gelişmedir.

5ay26*************************** *********************************************** ************************************ 4844SSZ olan ilgili işlem türünün RLP olarak değiştirilmesi, Cancun’un iki a anlamına gelir SSZ EIP'ler*****, yaniEIP'ler 6475 ve 6493** yükseltme için Cancun'dan taşındı***

EIP 6475X

  • Giriş: EIP 4844'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önetici Katmanı Çekirdek Geliştiriciler Toplantısı sırasında EIP hakkında bir tartışma yapıldı. 4844 için SSZ serileştirme formatının tartışılması, başlangıçta geliştiricilerin blob işlemleri yoluyla SSZ formatının erken bir yinelemesini EL'e sunmaya meyilli olduklarını ve sonunda geliştiricilerin tüm işlem türlerini RLP'den SSZ'ye yükseltmeyi planladıklarını, ancak yolunun belirsiz olduğunu gösterdi. ve kesinlikle Cancun yükseltmesinde uygulanmadı, geliştiriciler SSZ'yi EIP-4844'ten kaldırmayı tartışıyorlar. Uzun tartışmalardan sonra, geliştiriciler SSZ'yi EIP-4844'ün** EL uygulamasından kaldırmayı kabul ettiler, ancak EIP6475**** kaldırılmadı. **SSZ-> RLP değişiklikleri, Cancun'daki iki SSZ'ye artık ihtiyaç olmadığı anlamına gelecek EIP'ler: ** Bu nedenle EIP'ler 6475 ve 6493 yükseltmeler için Cancun'dan taşınacak. **

EIP 6493X

  • 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şiklikler
  • Giriş: Basit SerialiZe, beacon zincirinde kullanılan serileştirme yöntemidir.
  • SS Değişiklikler aynı zamanda diğer üç destekleyici teklifi de içeriyor, bu sefer sadece 6465 tanıtıldı. *EIP 6465: SSZ geri çekme kökü, mevcut Merkle-Patricia'yı tanımlar Trie (MPT) taahhütlerinin Basit Serileştirmeye (SSZ) geri çekilmesine geçiş; *EIP 6404 / EIP 6466:
  • Her ikisi de mevcut bir Merkle-Patricia'yı tanımlar Trie (MPT) taahhütleri, Basit Serileştirmeye (SSZ) geçiş sürecindedir.
  • EIP-6404 — SSZ işlem kökü
  • EIP-6466 — SSZ makbuz esası

Tim Beiko***, 5ay26*** tarihindeki bir çekirdek geliştirici toplantısında Cancun'un genişletilmesiyle ilgili gelecekteki gelişmeleri önerdi. aşağıdaki beşEIP ile sınırlıdır:EIP 5920,5656,7069,4788 ve 2537, bu kapsamda takip teklifleri üretilecektir. takipEIP 5656*** veEIP 4788 resmi bir yükseltme teklifi olarak onaylandı,5920,7069 ve2537 kaldırıldı, buradaEIP 5920*, geliştiricinin ETH** aktarma yolunun potansiyel yan etkileri ve ayrıca yükseltmeden dolayı bitmemiş muhakeme, test ve güvenlik çalışmasıyla ilgili endişesinden kaynaklanmaktadır. kaldırmak. ***

EIP 5920**:**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ştirmeyi, muhtemelen istemeden başka şeyler yapmayı gerektirir.
  • Değiştirmek:
  • Yeni bir işlem kodu tanıtıldı: ( PAY) PAY_OPCODE burada:
  • Yığından iki değer çıkar: addrthen val.
  • 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.
  • Anlamı: tasarruf gaz**. ** *Güncelleme: 09.06.23 PAY, ETH'nin transfer edilme şeklinin olası yan etkileri ve teklifin geçmesi için gereken muhakeme, test ve güvenlik çalışmasıyla ilgili endişeler nedeniyle yükseltmeden kaldırıldı.

EIP 7069X

  • Giriş: Değiştirilmiş CALL talimatı
  • DEĞİŞTİRİLMİŞ: 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 mevcut gazının biraz daha doğru 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.
  • **Şu anda **63/64'ü kullanıma sunuyor Kurallar:
  • Silinen arama derinliği incelemesi;
  • Çağrılan davranışı gerçekleştirmeden önce en az 5000 gaz ayırdığınızdan emin olun;
  • Aranan davranış için en az 2300 gaz olduğundan emin olun.
  • Sübvansiyon 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 2300 alır gaz çok sınırlı işlemleri gerçekleştirmek için kullanılı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ğildir) ve sabit bir gaz miktarı belirlediğinden, insanların bunları şu şekilde belirlemesinin bir yolu yoktur: gaz fiyatı ayarlanabildiği sürece gaz ne tür hesaplamaları destekleyebilir?
  • Önem: ** İleride ** EOF **'nin piyasaya sürülmesinin önünü açar ve büyük sözleşmelerin işletilmesi için daha uygundur. **
  • Kaldırılan gaz opsiyonelliği: yeni direktifler gazın belirtilmesine izin vermiyor ancak gazı sınırlamak için "63/64. kuralına" (esas olarak EIP-150'deki çok sayıda IO operasyonu için gazın yeniden fiyatlandırılmasına atıfta bulunur, bu da belirli operasyonların gaz tüketimini artırır) güvenir. "Ödenek" kuralı etrafında işlem, değer gönderilip gönderilmediğine bakılmaksızın, arayan kişinin gazla ilgili hesaplamalar yapmasına gerek yoktur;
  • Yeni teklifi sunduktan sonra, kullanıcılar işlemde daha fazla gas göndererek her zaman Out'un üstesinden gelebilirler (tabii ki blok gas limitine tabidir) Gaz hatası.
  • Daha önce, depolama maliyetlerini yükseltirken (örn. EIP-1884, belirli işlem kodları için gazı artırdı), aramalarına yalnızca sınırlı miktarda gaz gönderen bazı sözleşmeler, 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 reddedilerek gaz fiyatı değişikliklerinden büyük ölçüde etkilenmemeleri sağlanır. Bu işlemler gaz gözlemlenebilirliğini ortadan kaldırmak için gerekli olduğundan, EOF mevcut talimatların yerine bunları gerektirecektir;
  • Daha uygun durum dönüş kodları: Daha ayrıntılı durum kodları döndüren kullanışlı işlevler sunulmuştur: başarı (0), geri yükleme (1), başarısızlık (2) ve gelecekte genişletilebilir.

EIP 2537**:**X

  • Giriş: BLS12-381 eğri manipülasyonunun ön derlemesi.
  • Değiştirildi: BLS imza doğrulamasını verimli bir şekilde gerçekleştirmek ve SNARKs doğrulaması vb. işlemleri gerçekleştirmek için gereken sete önceden derlenmiş 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ğlar**. **

PR 3175 *** Bahsedildi ancak kısa listeye alınmadı, başka tartışma yok ***

PR 3175**:**X

  • Özet: Bu teklif, cezalandırılan doğrulayıcıların kuyruktan çıkarıldığında blok önermesini 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 blok önerebilecektir. 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 Core Developers Consensus Toplantısına göre, PR 3175, bir EIP olarak biçimlendirilme sürecindedir ve eğik çizgiyle işaretlenmiş doğrulayıcıların blok teklifçileri olarak seçilmesini önlemek için güvenlik nedeniyle EIP-6987 olarak değiştirilecektir.

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, kapasite 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ıyı, iletişimi ve birlikte çalışabilirliği optimize etmek gibi birlikte çalışabilirlik;
  • Beklenen veriler: testnet 4844, karşı tarafı azaltabilir Toplama maliyetinin %50'si; EigenLayer ve Celestia'nın teknik çözümleri çok fazla açıklama yapmadı ve verileri değerlendirilemiyor; Ethstorage, DA maliyetinin orijinalin %5'ine düşeceğini tahmin ediyor; Topia maliyeti düşürmeyi bekliyor 100~1000 kez.

2.** Cancun yükseltmesi Danksharding**'in gelecek 2~5 yıllarında, DA katman projelerinin**** altın geliştirme dönemidir.

  • Katman Güvenlik üst sınırı olan 2, benimsediği DA katmanına bağlıdır.Proto-Danksharding, daha ucuz durum verisi depolama yoluyla depolama protokolüne, modüler protokole ve L1 depolama genişletme ağı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ı duyuru 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ı garanti etmek değildir. tüm tarihsel verilerin sonsuza dek saklanması. Daha doğrusu amaç, son derece güvenli bir gerçek zamanlı ilan panosu sağlar ve daha uzun süreli depolama yapmak için diğer merkezi olmayan protokoller. ）；
  • **İkinci olarak, **Danksharding ***DA ** maliyetini düşürür, ancak gerçek iniş zamanı ve veri kullanılabilirliği sorunlarının da çözülmesi gerekir. **
  • DA** maliyet azaltma: **Bu güncellemeden önce, toplamadan Ethereum ana zincirine veri yayınlamak için calldata'yı çağırmak gerekliydi ve bu kodu çağırmanın gaz ücreti çok pahalıydı, bu da katman En büyük 2 ödeme, EIP 4844, depolama maliyetlerini büyük ölçüde azaltacak ve dolayısıyla DA maliyetlerini azaltacak olan, toplamalara özgü ek bir veri alanı olarak veri blobunu sunar.
  • Gerçek iniş süresi uzundur ve iyileştirilmiş ** TPS ** ve azaltılmış ** gaz ** hala sınırlıdır, bu nedenle ** DA * için iyidir * Müteakip sürekli geliştirmedeki katman projeleri:
  • polynya'da danksharding hakkında güvenilir Güvenlik verisi parçalama yazısında uygulamanın 2-5 yıl süreceği belirtiliyor;
  • ** Yere inse bile ** TPS ** artırabilir ve ** gazı ** azaltabilir büyüklükler hâlâ sınırlıdır:** *EIP 4844 ş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. 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. İdealleş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, iniş için uzun süre + Sınırlı fiili değişiklikler fayda sağlayacaktır DA Katman projeleri, bazıları Celestia, gibi ** Eigenda** ** ** DA ** projesi, gelecekte ** Danksharding ** ile rekabet edebilmek için ** TPS ** daha ucuz maliyetle ve daha hızlı geçebilir*, ETH depolama Topia** ve diğer yeni DA projeleri de inişten önce pazardaki boşluğu doldurabilir. **
  • Veri depolama ve veri kullanılabilirliği sorunları gibi teknik sorunların da ele alınması gerekiyor:
  • 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 konsensüs 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'ın kendisi, kendisi ile ilgili verileri depolar, Ethereum portal ağı (şu anda geliştirme aşamasındadır) 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 protokolü, modüler protokol ve L1 depolama genişletme ağından faydalanacaktır:
  • Geçmiş verileri çağırma talebi, merkezi olmayan depolama protokolleri veya üçüncü taraf dizin 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 yerleşim katmanı yerleşimden ve düşük maliyetli ve yüksek kapasiteli veri kullanılabilirliği katmanı garantiden sorumludur;
  • Eth gibi iyi L1 depolama genişletme ağı daha düşük bir depolama maliyetiyle programlanabilir depolama için ikinci katman bir çözüm sağlayabilen depolama.

**3.**Cancun yükseltmesi L2çeşitlilik, L3, RAAS ve Veri Kullanılabilirliği ve Diğer İzler

  • L2 parça analizi:
  • Arbitrum gibi Head Layer2 Yörünge, OP Yığın, Poligon2.0, Fraktal Scaling (StarkWare altında) ve HyperChain (zkSync altında) dahil olmak üzere 5 proje faydalanacaktır. Blob'un getirdiği depolama ücreti indirimi, önceki kısıtlı katman serisini yapacaktır. 2 Geliştirme maliyeti ve ölçeklenebilirlik sorunları büyük ölçüde iyileştirildi ve veri çıkışı büyük ölçüde iyileştirildi.Maliyet sorununu çözdükten sonra, ana katman 2 Belirli işlevler için son derece özelleştirilmiş bir çok zincirli eşzamanlı L3 ekolojisini konuşlandırmaya devam etme fırsatı olacaktır;
  • İkinci katman Layer2 ile ana katman Layer2 arasındaki işletim maliyetleri farkı azaltılarak Aztec, Metis, Boba, ZKspace, layer2.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ğrulansa da, Starkware'in Cario, Move serisi dilleri, Wasm tarafından desteklenen C, c++, C# ve Go serisi dilleri gibi çeşitli programlama dilleri hala mümkün. Daha fazla web2 geliştiricisi tanıtın.
  • 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 parçasıyla ilgili sorun şu ki, OverHype olabilir ve hatta RAAS parçasının kendisi hakkında şüpheler var. ** ** 5 ** tura** layer2 ** rekabetiyle karşı karşıya kalan çeşitli yeni ** DA **'nın ortaya çıkışı, yeni projeler oluşturabilir mi koymak zorundayız yolda bir soru işareti. **
  • İlk olarak, başlık katmanı 2 Uygulama zincirinin konuşlandırılmasının avantajı, ağ çerçevesinin bütünlüğünde ve zincirler arasındaki 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ında ve fiili bir ürün etkileşimi yok.RAAS'ın fiili ilerlemesi dikkate alındığında, teknik formlar ve Gelecekte katman3'ün ekolojik avantajları, RAAS'ın gerçek talebi şüphelidir.
  • OP Departmanı: OP olmasına rağmen yığının ana kaya yükseltmesi+ 4844'ün lansmanı, maliyet ve verimlilikte küçük bir artış sağladı, ancak artış çok çekici 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. Ancak şu anda piyasada bulunan ZK Çoğu RAAS, zinciri çatallamak için hala önde gelen projeleri (ZkSync gibi) kullanıyor ve engeller hala güçlü değil.
  • SO, kısa vadeli OP RAAS** **** layer3 ** inmeden önce hala geliştirilecek alan var. Uzun vadede, ** ZK RAAS ** ve ** layer3 ** geleceğin trendi olabilir. ** *ZK RAAS, 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 kovada sadece 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'un ikinci önemli önerisi SEFDESTRUCT'ı yükseltiyor kaldırma, Ethereum'un güvenliğini daha da artıracaktır.Aynı zamanda, silme işleminden sonra olası programatik hesap güncelleme sorunları için, bu durumu iyileştirmek için yeni bir işlem kodu SETCODE hazırlanır;
  • Cancun Yükseltmesi için Üçüncü Teklif EIP'si 1153, ilk olarak gaz tasarrufu yapabilen, ikinci olarak çerçeveler arası iletişim sorununu çözebilen ve son olarak, geri ödeme sorununu dikkate alması gerekmeyen Verkle ağacı gibi gelecekteki depolama tasarımının önünü açabilen geçici bir depolama işlem kodu ekler. geçici depolama;
  • Cancun yükseltmesi için dördüncü teklif EIP 5656, 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ükseltmesi için beşinci teklif EIP'dir. 4788, Ethereum ağındaki farklı protokoller ve uygulamalar arasındaki iletişimi daha verimli ve güvenli hale getirebilir ve ayrıca taahhüt havuzları, köprüleme ve yeniden paylaşım protokolleri için daha güvenilir tasarımlara izin verebilir;
  • Cancun, önerilen en son (15 Haziran 23) CL merkezli EIP yükseltmelerini yükseltir: EIP 6988, EIP 7044, EIP Söz verenlerin deneyimini iyileştirmek ve ağ güvenliğini iyileştirmek gibi ayrıntılarla Ethereum'un güvenliğini ve kullanılabilirliğini artıran 7045.
  • Silinen teklifler arasında SSZ-> RLP'nin dönüşümü iki SSZ'yi yapar EIP (EIP) 6475 ve EIP
  1. Cancun yükseltmesinden kaldırıldı; EOF ile ilgili teklifler, Şangay yükseltmesinden çıkarıldıktan sonra Cancun yükseltmesinden çıkarıldı ve şu anda daha sonraki günlük yükseltmede doğrudan uygulanabileceği düşünülüyor; EVMMAX, bazı EIP'lerden kaynaklanıyor EOF uygulama Alt Kümesi ile ilgili olduğundan, ETH'nin aktarılması yolunda var olabilecek potansiyel yan etkilerin yanı sıra teklifi geçmek için gereken muhakeme, test ve güvenlik çalışmaları göz önünde bulundurularak EOF ile birlikte yükseltilmek üzere Cancun'un dışına taşındı. , EIP 5920 yükseltmeden kaldırıldı.

**5. *zkml ile ilişki ve hesap soyutlama

zkml* üzerinde çok az etki

  • ZKML sıfır bilgi kanıtıdır (Sıfır Bilgi) ve makine öğrenimi (Makine Learning); **blockchain ve ML modelinin kombinasyonu, makine öğreniminin gizlilik koruma ve doğrulanabilirlik sorunlarını çözer:
  • Gizlilik koruması: makineyi eğitim için beslemek için veri olarak büyük miktarda kişisel bilgi kullanmak gibi girdi verilerinin gizliliği, kişisel bilgilerin gizliliği önemli bir gerekliliktir; veya model parametreleri, projenin temel rekabet gücüdür ve rekabet engellerini korumak için şifreleme de gereklidir. Bunlar gibi güven sorunları ortaya çıktığında, makine öğrenimi modellerinin daha büyük ölçekli veri ve uygulamalar elde etmesi engellenir.
  • 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 ** depolama gereksinimlerinin ** DA ** ile çok az ilgisi vardır: **Boşluk gibi bir şeye ihtiyacınız var Bu ayrı depolama yapısının temel teknolojisi, "SQL korumalı" yeni güvenlik protokolüdür. Basitçe söylemek gerekirse, blok zincirinin yanında bir veri ambarıdır ve geliştiricilerin basit bir SQL formatında zincir içi ve zincir dışı bağlantı kurmasına olanak tanır. veri ve sonuçları doğrudan akıllı sözleşmeye yükleyin;
  • ZK-SNARKs **** ZKML **'deki ** ZK **'nin ana biçimidir ve ** **ML'nin zincir üstü hesaplamasına uyarlanabilir ** ** Kriptografinin gelişmesiyle birlikte, özellikle özyinelemeli **SNARK kanıt faydalı olacaktır ZKML Zincire iniş:
  • ZK-SNARK'lar yüksek kompaktlık ile 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 tür kanıt yalnızca bir kez gerekir Doğrulayıcı ile doğrulayıcı arasındaki etkileşimin doğası, ZK-SNARK'ları pratik uygulamalarda verimli ve pratik kılar ve zincirdeki makine öğreniminin bilgi işlem gücü gereksinimleri için daha uygundur.
  • Şu anda zincir üzerinde eğitim yapılamaz ve yalnızca zincir dışı hesaplamaların sonuçları zincirde 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). Büyük model ZK provaları, zincir üzerinde desteklenemeyen daha yüksek işlem gücü gerektirir. ZK-SNARK'lar, yalnızca küçük ölçekli ve az miktarda hesaplama ile makine öğrenimi sıfır bilgi kanıtını destekler; yani, bilgi işlem gücünün sınırlandırılması, ZKML blockchain uygulamalarının gelişimini etkileyen önemli bir faktördür ve zincir, yalnızca off- zincirleme hesaplamalar

İyi hesap soyutlaması

  • Her şeyden önce, Cancun yükseltmesi belirli bir ölçüde azaltabilir ZK toplama Ücret Kanıtı:
  • Mevcut zkSync işlem ücreti 3 duruma bağlıdır:
  • Doğrulayıcı tarafından SNARK kanıtları oluşturmak ve bunları doğrulamak için tüketilen sabit kaynakların 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.
  • Dolayısıyla 4844'ün getirilmesi durumunda ana şebeke sıkışıklığından kaynaklanan artan gas ücretleri sorunu ortadan kalkacağı gibi ZKP ispatlarının maliyeti de bir nebze olsun düşürülebilecektir.Kanıt üretme maliyetine göre çok fazla olmasa da, ZK'nin henüz başlangıç aşamasında olduğu düşünülürse, ZK serisinin gelecekteki gelişim trendi hafife alınmamalıdır.
  • İkincisi, hesap soyutlama, geleneksel ** tx ** işlemlerini ** kullanıcı işlemine dönüştürür ve ardından ** kullanıcı işlemlerine kullanım ECDSA * * Bloklar halinde paketlenmiş, zincirdeki depolama eskisinden daha fazla yer kaplıyor, bu nedenle depolama gereksinimleri daha yüksek;
  • **Sonra hesap soyutlama ve ** ZK toplama birbirini tamamlayabilir:
  • Mevcut hesap soyutlama sorunu Gazdır Ücret pahalıdır, çünkü çok fazla adım vardır ve akıllı sözleşmeler söz konusudur, bu nedenle Gas'a yol açan çok fazla veri vardır. Ücret pahalıdır ve ZK Toplama'nın avantajı, verileri azaltabilmesidir;
  • Hesap soyutlaması güvenliği garanti etmeyi zorlaştırır: AA birden fazla sözleşme içerdiğinden güvenlik bir sorundur, ancak gelecekte L2'nin kademeli olarak oluşturulmasından sonra fikir birliği katmanı değişmeyecek, akıllı sözleşmelerin daha fazla kullanımı olacak ve güvenliği ZK'nın yardımıyla hesap soyutlaması da garanti edilebilir Güvenilir toplama doğrulaması, güvenliği daha da artıracaktır.
  • 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;
  • Yapay zeka ve zincirdeki 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 ** ZK ile entegrasyona kadar olacaktır. Toplama ** tamamlayıcılığı ve ** AI ** teknolojisi ile kombinasyonu, hesap soyutlamanın gelecekteki gelişimine kademeli olarak fayda sağlayacaktır. **

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

  • **Şu anda **Layer2 **, ** Solana ** ile benzer bir performansa (gecikme ve aktarım hızı açısından) veya ** Near ** gibi bir performansa sahip değildir parçalama performansı ve ** Sui ** ve ** Aptos ** gibi paralel yürütme performansı olmaması, Cancun yükseltmesi Ethereum'un lider konumunu iyileştirdi; **
  • Cancun yükseltmesinden sonra, birkaç önemli geliştirme süresi tahmin edilmektedir Tam-Danksharding** (2~5 yıl), *MEV * ve ** PBS iniş (1~3 yıl), hesap soyutlama (1~2 yıl), ***ZK * * *Her şey (3~6 yıl), EOF ve geliştirici deneyimi (uzantısı kaç kez gördünüz?). **

** kırbaç**

  • Hedef: MEV problemlerini çözmeye odaklanmak.
  • Çözüm: MEV'yi uygulama katmanında "Teklif Sahibi-Oluşturucu Ayrımı (PBS)" aracılığıyla en aza indirin. Bu sırada, bloblar optimize edilebilir ve ön onay hizmetleri veya ön alım korumaları sunulabilir.
  • PBS, blok üreticilerinin 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 dışsallaştırma fikri olan MEV sorunlarını hafifletecektir.
  • PBS'nin tamamlanma derecesi hala çok düşüktür ve daha olgun olanlar Harici MEV çözümleri ile işbirliği - flashbot'larla mevboost.
  • "Enshrined" in gelişmiş versiyonu Proposer-Builder Separation (ePBS)" daha düşük tamamlanma derecesine ve daha uzun bir döngüye sahiptir ve kısa vadede uygulanmayacağı tahmin edilmektedir. PEPC ve Optimistic'in ilerici versiyonları da vardır. PBS çerçevesinin esnekliğini ve uyarlanabilirliğini artıran aktarma

** 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 hafif hale getirin.
  • Aynı zamanda, Verge yol haritasına L1'in ZKizasyonu açıkça eklendi.ZK, gelecekteki genişleme ve hızlanmanın genel eğilimi olacak;
  • Çözüm: SNARK tabanlı hafif istemciler de dahil olmak üzere eski ispat sistemini değiştirmek için zk-SNARK'ları tanıtın; mutabakat durumu değişiklikleri için SNARK'lar; Enshrined Toplamalar.
  • 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, yalnızca kanıt olarak yolun kendisini sağlayan duruma özgü Merkle ağaçlarına göre daha verimli bir alternatiftir. ispatlar Merkle ispatlarından 3 kat daha etkilidir.
  • kutsal Toplama, L1 üzerinde bir tür konsensüs entegrasyonuna sahip bir Toplama anlamına gelir. Avantajı, L1'in fikir birliğini devralması ve toplama yükseltmelerini gerçekleştirmek için yönetişim belirteçlerine ihtiyaç duymamasıdır. Aynı zamanda, zincirin 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.

** tasfiye**

Tasfiye, 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 Durağanlığı (EIP-4444), müşterilerin bir yıldan eski geçmiş verileri budamasına ve P2P düzeyinde hizmet vermeyi durdurmasına olanak tanır.

  • Devlet uykuda. Durum büyümesini ele almaya gelince, iki ana hedef vardır: durumu yalnızca bir blok oluşturmak için kullanma hedefine atıfta bulunan, ancak bunu doğrulamayan zayıf vatansızlık; Erişilen durum. Durum hazırda bekletme, bir düğümün depolaması gereken durumu toplam 20-50 oranında azaltmalıdır. GB.
  • Beşinci aşamada Arınma, EIP 4444, Yol Haritasına açıkça yazılmıştır, EIP-4444, müşterinin bir yıldan daha eski verileri temizlemesini gerektirir ve bu aşamada, GAS ve EVM ön derleme mekanizmasının basitleştirilmesi vb. gibi bazı EVM optimizasyon çalışmaları devam etmektedir;

** Savurganlık**

  • Son altıncı aşamada Splurge, EIP 4337'den de bahsedildi.Cüzdan ekolojisi için uzun vadeli bir yerleşim planı önerisi olarak hesap soyutlama, gaz, sosyal kurtarma cüzdanları vb.

Referans malzemeleri:

  • Ethereum çekirdek geliştirme toplantısı güncellemesi: *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #148 yazma *Ethereum Tüm Çekirdek Geliştiriciler Arama #149 Yazma *Ethereum Fikir Birliği Katmanı Çağrısı #99 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #150 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #151 yazma *Ethereum Mutabakat Katmanı Çağrısı #100 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #152'yi kullanır yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı No. 153 yazma *Ethereum Orijinal Sihirbazlar forum tartışması: *Ethereum Tüm Çekirdek Geliştiriciler Çağrı No. 156 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı No. 157'yi kullanır yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #158'i kullanır yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı No. 159 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #160'ı kullanır yazma *Ethereum Tüm Çekirdek Geliştiriciler Fikir Birliği Çağrısı #108 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #161'i kullanır yazma *Ethereum Tüm Çekirdek Geliştiriciler Fikir Birliği Çağrısı #109 yazma *Ethereum Tüm Çekirdek Geliştiriciler Çağrı #162'yi kullanır yazma *Ethereum Tüm Çekirdek Geliştiriciler Fikir Birliği Çağrısı #110 yazma *Tim, en son Ethereum Cancun yükseltmesi (09.06.23) hakkında tweet attı:
  • Ethereum Tüm Çekirdek Geliştiriciler Fikir Birliği Çağrısı #111 yazma *Ethereum Tüm Çekirdek Geliştiriciler Fikir Birliği Çağrısı #112 yazma
  • Ethereum yükseltmesi ile ilgili içerik:
  • Kendi kendini yok etme koduna giriş:
  • EVMMAX teklifini ve BLS12-381'i keşfedin
  • Cancun yükseltmesi EIP-4844'ün yanı sıra başka neler içerecek? Ethereum'un en son fikir birliği çağrısına bir göz atın
  • Ethereum Shanghai yükseltmesinde hangi yeni içerikler eklendi?
  • tweet'ler:
  • TAMAM Girişimler: Ethereum Shanghai'ın yükseltilmesinden sonra Cancun, potansiyel yatırım fırsatlarını yükseltiyor- Öngörü Haberleri
  • Yüksek profilli EIP-4844'e ek olarak, Cancun yükseltmesi hangi önerileri içerecek?
  • V God: Silme işlemi için dikkate alınmaya değer EVM işlevi
  • Proto-Dansharding SSS
  • V God tarafından önerildi丨Ethereum'un parçalama yol haritasının derinlemesine anlaşılması için bu raporu okumak yeterlidir
  • Ethereum'un yeni yükseltme planı olan Danksharding'i anlamak için bir makale
  • Ethereum'un en son yol haritasındaki ilginç gerçekleri ve gizli sırları deşifre edin
  • Vitalik: SELFDESTRUCT neden Ethereum'un ekolojisine yarardan çok zarar veriyor?
  • Ethereum vizyonu:
  • Blok işleri Araştırma Görevlisi Brrr: Proto-Danksharding Ethereum'un L1'ini Nasıl Hızlandırıyor? Toplama ölçeklenebilirliği
    1. Ethereum ACDC toplantısı: Deneb yükseltmesinin nihai kapsamını ve EIP-7044 dahil üç teklifi tartışın
  • KOL Stacy Muur'un Ethereum ölçeklendirme çözümlerinin gelişimine bakışı: OP Yığın, Keyfi Yörünge, Çokgen 2.0
  • Üç tür Toplamanın yatay karşılaştırması: klasik Toplamalar (İyimser/ZK Toplamalar）、Kutsanmış Toplamalar, Egemen Toplamalar
  • [AMA] Biz EF Research'üz (Bölüm 8: 07 Temmuz, 2022):
  • 2023'te yeniden düşünmeye değer 3 popüler parça
  • Karadağ EDCON 2023'ün Sonuna Dair Düşünceler: Altyapı ve Uygulama Trendlerine Bir Bakış
  • AI ve Web3'ü birleştirme olasılığının sonsuz fantezisi
  • AI+Web3: Yapay zeka ve blockchain entegrasyonunu keşfetme
  • zk-rollup ve op-rollup'ı karşılaştırma: neden geçerli zkSync'in doğrulama yönteminden analiz edilmesi Benzin ücreti yüksek
  • "Ciltlere hacim ekleme": Toplama döneminde hesap soyutlama çözümleri
  • ZKML'nin derinlemesine yorumu: teknik ilkeler, uygulama senaryoları, avantajlar ve zorluklar
  • ZKML: gizlilik koruması sağlamak için yapay zeka ile blok zincirini birleştiren bir model dağıtım teknolojisi
  • mümkün güvenlik verileri parçalama
  • EthStorage'ın kurucusu Qi ile diyalog Zhou | Veri Kullanılabilirliği ve Merkezi Olmayan Depolama
  • Bir makalede Ethereum geliştirme yol haritasının en son sürümünü okuyun
  • Uzay Hakkında Ve Zamana kısa bir giriş
  • Orijinal teklif: *EIP 4844: *EIP 6780: *EIP 1153: *EIP 5920: *EIP 5656: *EIP 7069: *EIP 4788: *EIP 2537: *EVMMAX EIP'ler: *EIP 6601: *EIP 6990: *EOF değişiklikler: *EIP 663: *EIP 3540: *EIP 3670: *EIP 4200: *EIP 4750: *EIP 5450: *EIP 6475: *EIP 6493:
  • halkla ilişkiler 3175:
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
  • Pin
sitemap
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate.io app
Community
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)
    • About UsCareersPartnersUser AgreementRisk WarningPrivacy PolicyCookie PolicyMedia Kit100% Proof of ReservesLicenseSecurityGT User PrivilegesGate ChainCalendarLaw EnforcementSummitsGate Ventures
    Buy CryptoSell CryptoSpot TradingFutures TradingLeveraged TokensStartupNFTGate PayGate LifeGift CardGate OTCGate CharityGate CardGate Shop
    VIP BenefitsUser FeedbackAnnouncementFeesHelp CenterSubmit a RequestListingSmart Contract SecurityDevelopersVerification SearchP2P Merchant ApplicationP2P Blue V ApplicationAffiliate Program
    Gate LearnCrypto CoursesCrypto GlossaryCryptocurrency PricesBig DataBitcoin Halving
    Gate.io © 2013-2025.