Ethereum'ın karşılaştığı zorluklardan biri, varsayılan olarak herhangi bir blok zinciri protokolünün şişmesi ve karmaşıklığının zamanla artmasıdır. Bu iki yerde olur:

• Tarihsel veri: tarih boyunca yapılan herhangi bir işlem ve oluşturulan herhangi bir hesap, tüm istemciler tarafından sonsuza dek saklanmalı ve ağa tam senkronizasyon yapan yeni istemciler tarafından indirilmelidir. Bu, ağın kapasitesi aynı kalsa bile, istemci yükünü ve senkronizasyon süresini zamanla arttırır.
• Protokol özellikleri: yeni bir özellik eklemek eskisini kaldırmaktan çok daha kolaydır, bu da zamanla kod karmaşıklığının artmasına neden olur.

Ethereum'un kendisini uzun vadede sürdürebilmesi için, bu eğilimlerin her ikisine de karşı güçlü bir karşı baskıya ihtiyacımız var, bu da zaman içinde karmaşıklığı ve şişkinliği azaltıyor. Ancak aynı zamanda, blok zincirlerini harika yapan temel özelliklerden birini korumamız gerekiyor: kalıcılıkları. Bir NFT, işlem çağrı verilerine bir aşk notu veya zincir üzerinde bir milyon dolar içeren bir akıllı sözleşme koyabilir, on yıl boyunca bir mağaraya girebilir, dışarı çıkabilir ve hala orada okumanızı ve etkileşimde bulunmanızı beklerken bulabilirsiniz. DApp'lerin tamamen merkeziyetsiz hale gelme ve yükseltme anahtarlarını kaldırma konusunda kendilerini rahat hissetmeleri için, bağımlılıklarının onları bozacak şekilde yükseltilmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.

Temizlik, 2023 yol haritası.

Bu iki ihtiyaç arasında denge kurmak ve sıkıntıyı en aza indirmek veya tersine çevirmek, karmaşayı ve çürümeyi azaltırken sürekliliği korumak kesinlikle mümkündür; zihinlerimizi buna odaklarsak. Canlı organizmalar bunu yapabilir: çoğu zamanla yaşlanırken de, şanslı birkaç kişi değil. Hatta sosyal sistemler bile yapabilir.aşırı uzun ömürlü olmakBirkaç kez Ethereum zaten başarılar gösterdi: proof of work ortadan kalktı, SELFDESTRUCT opcode genellikle yok oldu ve beacon zincir düğümleri zaten eski verileri sadece altı aya kadar saklıyor. Ethereum için bu yolun daha genelleştirilmiş bir şekilde belirlenmesi ve uzun vadeli istikrarlı bir sonuca doğru ilerlenmesi, Ethereum'un uzun vadeli ölçeklenebilirlik, teknik sürdürülebilirlik ve hatta güvenliğinin nihai zorluğudur.

The Purge: ana hedefler

• Her düğümün tüm geçmişi kalıcı olarak depolamak için her düğümün ihtiyacını azaltarak veya kaldırarak istemci depolama gereksinimlerini azaltma ve belki de sonunda durumu bile azaltma
• Gereksiz özellikleri ortadan kaldırarak protokol karmaşıklığını azaltma

Bu bölümde

• Geçmiş süresi
• Durum süresi
• Özellik temizliği

Geçmiş sona erme

Bu sorunu nasıl çözer?

Bu yazının yazıldığı sırada, tam senkronize bir Ethereum düğümü gerekmektedir.yaklaşık 1.1 terabaytdisk alanı içinyürütme istemcisi, artı konsensüs istemcisi için başka birkaç yüz gigabayt daha. Bunun büyük çoğunluğu geçmiş hakkındadır: tarihi bloklar, işlemler ve makbuzlar hakkındaki veriler, çoğu yıllardır. Bu, bir düğümün boyutunun her yıl yüzlerce gigabayt artmasına neden olur, hatta gaz limiti hiç artmazsa bile.

Bu nedir ve nasıl çalışır?

Tarih depolama sorununu basitleştiren bir ana özellik, her bloğun bir önceki bloğa bir karmalı bağlantı aracılığıyla işaret etmesidir (ve diğer yapılar) , şu an için uzlaşmaya sahip olmak, tarihte uzlaşmaya sahip olmaktan yeterlidir. Ağın en son blok üzerinde uzlaşmaya sahip olduğu sürece, herhangi bir tarihi blok veya işlem veya durum (hesap bakiyesi, nonce, kod, depolama) herhangi bir tek aktör tarafından bir Merkle kanıtı ile birlikte sağlanabilir ve kanıt, başkalarının doğruluğunu doğrulamasına izin verir. Uzlaşma bir N/2-of-N güven modelidir, tarih ise bir1-of-N güven modeli.

Bu, geçmişi nasıl saklayabileceğimize dair birçok seçenek sunar. Doğal seçeneklerden biri, her düğümün verilerin yalnızca küçük bir yüzdesini depoladığı bir ağdır. Torrent ağları onlarca yıldır bu şekilde çalışıyor: ağ milyonlarca dosyayı tamamen depolar ve dağıtırken, her katılımcı bunlardan yalnızca birkaçını depolar ve dağıtır. Belki de sezgisel olarak, bu yaklaşım verilerin sağlamlığını mutlaka azaltmaz. Düğüm çalışmasını daha uygun maliyetli hale getirerek, her düğümün geçmişin rastgele %10'unu depoladığı 100.000 düğümlü bir ağa ulaşabilirsek, her veri parçası 10.000 kez çoğaltılır - her düğümün her şeyi depoladığı 10.000 düğümlü bir ağ ile tam olarak aynı çoğaltma faktörü.

Bugün Ethereum, tüm geçmişi sonsuza kadar saklayan tüm düğümler modelinden uzaklaşmaya başladı bile. Konsensüs blokları (yani proof of stake konsensüsü ile ilgili kısımlar) yalnızca ~6 ay boyunca saklanır. Bloblar yalnızca ~18 gün boyunca depolanır. EIP-4444Ethereum, tarihi bloklar ve makbuzlar için bir yıllık depolama süresi getirmeyi amaçlıyor. Uzun vadeli bir hedef, her düğümün her şeyi depolamaktan sorumlu olduğu ve ardından Ethereum düğümlerinden oluşan eşler arası bir ağın eski verileri dağıtılmış bir şekilde depoladığı uyumlu bir süre (~18 gün olabilir) oluşturmaktır.

Silme kodları, çoğaltma faktörünü aynı tutarken sağlamlığı artırmak için kullanılabilir. Aslında, bloblar veri kullanılabilirliği örneklemesini desteklemek için zaten silme kodlu olarak gelir. En basit çözüm, bu silme kodlamasını yeniden kullanmak ve yürütme ve konsensüs blok verilerini bloblara da koymak olabilir.

Mevcut araştırmalar için bazı bağlantılar nelerdir?

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrentlar ve EIP-4444: https://ethresear.ch/t/torrentlar-ve-eip-4444/19788
• Portal ağı:https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• Portal ağı ve EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• Portal'da SSZ nesnelerinin dağıtık depolanması ve alınması:https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• Gaz limitini nasıl yükseltebilirim (Paradigm):https://www.paradigm.xyz/2024/05/gaz-limitsini-nasıl-yükseltebilirsiniz-2

Yapılacak ne kaldı ve ne gibi fedakarlıklar var?

Ana kalan iş, en azından yürütme geçmişi, ancak sonuçta uzlaşma ve bloklar için de beton bir dağıtılmış çözüm oluşturmak ve entegre etmektir. Bunun için en kolay çözümler, (i) mevcut bir torrent kütüphanesini basitçe tanıtmak ve (ii) Ethereum'a özgü bir çözüm olanPortal ağı. Her ikisi de tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444 kendisi için bir hard fork gerektirmez, ancak yeni bir ağ protokolü sürümü gerektirir. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesinde değer vardır, çünkü aksi takdirde tam geçmişi indirmeyi bekleyen diğer düğümlere bağlanan istemcilerin yanlış işlemesi riski vardır.

Ana ticaret dengesi, 'eski' tarihsel verilerin ne kadar kolaylıkla erişilebilir hale getirilmeye çalışılacağı arasında yapılır. En kolay çözüm, yarın eski tarihleri depolamayı durdurmak ve çeşitli merkezi sağlayıcılarla çoğaltma için mevcut arşiv düğümlerine güvenmektir. Bu kolaydır, ancak Ethereum'u kalıcı kayıtların yapıldığı bir yer olarak zayıflatır. Daha zor, ancak daha güvenli olan yol, önce tarihleri dağıtılmış bir şekilde depolamak için torrent ağını inşa etmek ve entegre etmektir. Burada 'ne kadar zorlukla denediğimizin' iki boyutu vardır:

1. Maksimum büyüklükte bir düğüm kümesinin gerçekten tüm verileri depoladığından emin olmak için ne kadar zorluyoruz?
2. Tarihsel depolamayı protokole ne kadar derinlemesine entegre ediyoruz?

(1) için maksimum düzeyde paranoyak bir yaklaşım, muhafaza kanıtı: aslında her bir proof of stake doğrulayıcısının geçmişin belirli bir yüzdesini saklamasını ve bunu yapıp yapmadıklarını düzenli olarak kriptografik olarak kontrol etmesini gerektirir. Daha ılımlı bir yaklaşım, her müşterinin geçmişin yüzde kaçını depoladığına dair gönüllü bir standart belirlemektir.

(2) için temel bir uygulama, zaten bugün yapılan işi almayı içerir: Portal zaten Ethereum tarihini içeren ERA dosyalarını depolar. Daha kapsamlı bir uygulama, bunu gerçekten senkronizasyon sürecine bağlamayı içerir, böylece biri tam tarih depolayan bir düğümü veya bir arşiv düğümünü senkronize etmek isteseydi, çevrimiçi başka arşiv düğümleri olmasa bile, Portal ağından doğrudan senkronize edebilirler.

Diğer kısımlarla nasıl etkileşime geçiyor?

Tarih depolama gereksinimlerinin azaltılması, bir düğümü çalıştırmayı veya hızlıca oluşturmayı son derece kolay hale getirmek istiyorsak, durumsuzluktan daha önemli olabilir: bir düğümün sahip olması gereken 1.1 TB'nin ~300 GB'si durum, kalan ~800 GB ise tarih. Bir Ethereum düğümünün akıllı bir saatte çalışması ve sadece birkaç dakika içinde kurulması vizyonu, hem durumsuzluk hem de EIP-4444'ün uygulanması durumunda gerçekleştirilebilir.

Geçmiş depolamanın sınırlanması, daha yeni Ethereum düğüm uygulamalarının sadece protokolün yeni sürümlerini desteklemesini ve böylece çok daha basit olmalarını mümkün kılar. Örneğin, 2016 DoS saldırıları sırasında oluşturulan boş depolama yuvaları artık tamamen kaldırıldığı için birçok satır kod güvenli bir şekilde çıkarılabilir.silindi. Artık proof of stake'e geçiş eski bir tarih olduğuna göre, müşteriler tüm proof-of-work ile ilgili kodları güvenle kaldırabilirler.

Durumun süresi dolmuş

Bu sorunu nasıl çözer?

Müşterilerin geçmişi depolama ihtiyacını kaldırsak bile, bir müşterinin depolama gereksinimi devam edecektir ve bu, hesap bakiyeleri ve nonce'lar, sözleşme kodu ve sözleşme depolamasındaki sürekli büyüme nedeniyle yılda yaklaşık 50 GB artacaktır. Kullanıcılar, mevcut ve gelecekteki Ethereum müşterileri üzerinde sürekli bir yük getirmek için tek seferlik bir maliyet ödeyebilirler.

Durum, tarihden daha zor bir şekilde "süresiz" olur, çünkü EVM, bir durum nesnesi oluşturulduğunda, her zaman orada olacağı ve herhangi bir işlem tarafından her zaman okunabileceği varsayımı etrafında temel olarak tasarlanmıştır. Eğer durumsuzluk tanıtırsak, belki de bu sorunun o kadar da kötü olmadığı bir argümanı var: sadece uzmanlaşmış bir blok oluşturucu sınıfının gerçekten durumu depolaması gerekecektir ve diğer tüm düğümler (hattadahil edilme listesiÜretim!) durumsuz çalışabilir. Bununla birlikte, durumsuzluğa çok fazla güvenmek istemediğimiz ve Ethereum'u merkezi olmaktan çıkarmak için durumu sona erdirmek isteyebileceğimiz bir tartışma var.

Bu nedir ve nasıl çalışır?

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu üç farklı şekilde gerçekleşebilir: (i) ETH'yi yeni bir hesaba göndermek, (ii) kodla yeni bir hesap oluşturmak, (iii) daha önce dokunulmamış bir depolama yuvasını ayarlamak), o durum nesnesi sonsuza kadar durumda olur. Bunun yerine, nesnelerin zamanla otomatik olarak süresinin dolmasını istiyoruz. Temel zorluk, bunu üç hedefi gerçekleştiren bir şekilde yapmaktır:

1. Verimlilik: süresi dolma sürecini çalıştırmak için büyük miktarda ek hesaplama gerektirmiyor
2. Kullanıcı dostu: biri beş yıl boyunca bir mağaraya girip geri dönerse, ETH'larına, ERC20'lerine, NFT'lerine, CDP pozisyonlarına erişimlerini kaybetmemelidir...
3. Geliştirici dostu: geliştiriciler tamamen yabancı bir zihinsel modelle değiştirmek zorunda kalmamalıdır. Ayrıca, bugün donmuş olan ve güncellenmeyen uygulamaların makul derecede iyi çalışmaya devam etmesi gerekir.

Bu hedefleri yerine getirmeden sorunu çözmek kolaydır. Örneğin, her durum nesnesinin sona erme tarihi için bir sayaç depolamasını sağlayabilirsiniz (bu, her okunduğunda veya yazıldığında otomatik olarak gerçekleşebilen ETH yakılarak uzatılabilir) ve süresi dolmuş durum nesnelerini kaldırmak için durum arasında döngü yapan bir işleme sahip olabilirsiniz. Ancak bu, ekstra hesaplama (ve hatta depolama gereksinimleri) getirir ve kesinlikle kullanıcı dostu olma gereksinimini karşılamaz. Geliştiriciler de, bazen sıfıra sıfırlanan depolama değerlerini içeren uç durumlar hakkında akıl yürütmekte zorlanırlar. Sona erme zamanlayıcısını sözleşme çapında yaparsanız, bu, geliştiriciler için hayatı teknik olarak kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: geliştiriciler, devam eden depolama maliyetlerini kullanıcılarına nasıl "aktaracaklarını" düşünmek zorunda kalırlar.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır mücadele ettiği sorunlardır, bu arada ' gibi öneriler de yer almaktadır.blockchain kiralamaveyeniden doğuşSonunda, tekliflerin en iyi kısımlarını birleştirdik ve iki kategoriye 'en az kötü bilinen çözümler' olarak yaklaştık:

• Kısmi durum-süresi sona erme çözümleri
• Adres dönemine dayalı durum süresi önerileri.

Kısmi durum sona erme

Kısmi durum süresi dolma önerileri, aynı prensibe göre çalışır. Durumu parçalara böleriz. Herkes, hangi parçaların boş veya dolu olduğunun 'üst düzey haritasını' kalıcı olarak saklar. Her bir parçadaki veriler, yalnızca bu verilere yakın zamanda erişildiyse saklanır. Bir parça artık saklanmıyorsa, herhangi biri, veriyi sağlayarak bu veriyi geri getirebilir.

Bu teklifler arasındaki temel farklılıklar: (i) "son zamanlarda"yı nasıl tanımlıyoruz ve (ii) "parça"yı nasıl tanımlıyoruz? Bir somut teklif EIP-7736, "sap ve yaprak" tasarımı üzerine inşa edilmiştir Verkle ağaçları için tanıtıldıBu tasarımda, birbirine bitişik olan başlık, kod ve depolama yuvaları aynı 'sap' altında depolanır (herhangi bir durumsuzluk biçimiyle uyumlu olmakla birlikte, örn. ikili ağaçlar). Bir sapın altında depolanan veriler en fazla 256 * 31 = 7.936 bayt olabilir. Birçok durumda, bir hesabın tüm başlık ve kodu ve birçok önemli depolama yuvası aynı sapın altında depolanır. Bir sapın altındaki veriler 6 ay boyunca okunmadıysa veya yazılmadıysa, veriler artık depolanmaz ve yalnızca veriye ait 32 bayt taahhüt ('bağlantı') depolanır. Bu veriye erişen gelecekteki işlemler, verinin, bağlantıya karşı kontrol edilen bir kanıtla 'dirilenmesi' gerekecektir.

Benzer bir fikri uygulamanın başka yolları da vardır. Örneğin, hesap düzeyi ayrıntısı yeterli değilse, her bir ağacın 1/232 kesri benzer bir gövde yaprağı mekanizması tarafından yönetilecek şekilde bir düzen yapabiliriz.

Bu, teşvikler nedeniyle daha zor; bir saldırgan, istemcileri, çok büyük miktarda veriyi tek bir alt ağaca yerleştirerek ve her yıl tek bir işlem göndererek 'ağacı yenilemek' için kalıcı olarak saklamaya zorlayabilir. Yenileme maliyetini ağaç boyutuna bağlı hale getirirseniz (veya yenileme süresini ters orantılı hale getirirseniz), o zaman biri, onları aynı alt ağaca çok büyük miktarda veri koyarak başka bir kullanıcıyı rahatsız edebilir. Alt ağaç boyutuna dayalı olarak granüliteyi dinamik hale getirerek her iki sorunu da sınırlamaya çalışabilirsiniz: örneğin, ardışık her 216 = 65536 durum nesnesi bir 'grup' olarak ele alınabilir. Bununla birlikte, bu fikirler daha karmaşıktır; gövde tabanlı yaklaşım basittir ve teşvikleri uyumlu hale getirir, çünkü genellikle bir gövde altındaki tüm veriler aynı uygulamaya veya kullanıcıya aittir.

Adres-dönem tabanlı durum süresi önerileri

Tüm kalıcı durum büyümesini tamamen önlemek isteseydik, hatta 32 baytlık kısayolları bile? Bu, bir zor problemdir çünkü...@vbuterin/state_size_management#Resurrection-conflicts">resurrection çatışmaları: bir durum nesnesi kaldırılırsa, daha sonra EVM yürütmesi tam olarak aynı konuma başka bir durum nesnesi koyarsa, ancak bundan sonra orijinal durum nesnesi ile ilgilenen birisi geri gelir ve onu kurtarmaya çalışırsa ne olur? Kısmi durum sona erme ile, "tutam" yeni veri oluşturulmasını engeller. Tam durum sona erme ile, hatta sadece tutamı saklamaya gücümüz yetmez.

Adres-dönemi tabanlı tasarımı çözmenin en iyi bilinen fikridir. Tüm durumu depolayan tek bir durum ağacı yerine, sürekli büyüyen bir durum ağacı listemiz var ve okunan veya yazılan herhangi bir durum en son durum ağacında kaydedilir. (düşünün: 1 yıl) her dönemde bir yeni boş durum ağacı eklenir. Eski durum ağaçları dondurulur. Tam düğümler yalnızca en son iki ağacı saklaması beklenir. Bir durum nesnesi iki dönem boyunca dokunulmadıysa ve böylece bir geçerliğini yitirmiş ağaca düştüyse, okunabilir veya yazılabilir, ancak işlem için Merkle kanıtı kanıtlamalıdır - ve bir kez yaptığında, bir kopyası en son ağaçta tekrar kaydedilecektir.

Tüm kullanıcılar ve geliştiriciler için kullanıcı dostu bir hale getirmek için önemli bir fikir, adres dönemleri kavramıdır. Bir adres dönemi, bir adresin bir parçası olan bir sayıdır. Ana kural, N adres dönemine sahip bir adresin, yalnızca N döneminden sonra okunabileceği veya yazılabileceğidir (yani durum ağacı listesi N uzunluğuna ulaştığında). Yeni bir durum nesnesi kaydediyorsanız (örneğin yeni bir sözleşme veya yeni bir ERC20 bakiyesi), durum nesnesini N veya N-1 olan bir sözleşmeye yerleştirmeyi sağlarsanız, öncesinde hiçbir şey olmadığına dair kanıtlar sunmanız gerekmeden hemen kaydedebilirsiniz. Öte yandan, eski adres dönemlerindeki durum eklemeleri veya düzenlemeleri bir kanıt gerektirir.

Bu tasarım, Ethereum'un mevcut özelliklerinin çoğunu korur, ekstra hesaplamada çok hafiftir, uygulamaların neredeyse bugün olduğu gibi yazılmasına izin verir (ERC20'lerin, N adres periyoduna sahip adreslerin bakiyelerinin, kendisi de N adres periyoduna sahip bir alt sözleşmede saklanmasını sağlamak için yeniden yazılması gerekecektir) ve "kullanıcı beş yıl boyunca bir mağaraya girer" sorununu çözer. Ancak, büyük bir sorunu var: adreslerin adres dönemlerine uyması için 20 baytın ötesine genişletilmesi gerekiyor.

Adres alanı uzantısı

Bir öneri, bir versiyon numarası, bir adres dönem numarası ve genişletilmiş bir hash içeren yeni bir 32 byte adres formatının tanıtılmasıdır.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

Kırmızı bir sürüm numarasıdır. Burada turuncu renkte boyanan dört sıfır gelecekte bir parça numarasını alabilecek boş alan olarak düşünülmüştür. Yeşil bir adres dönem numarasıdır. Mavi, 26 baytlık bir karma değeridir.

Buradaki temel zorluk, geriye dönük uyumluluktur. Mevcut sözleşmeler 20 bayt adresler etrafında tasarlanmıştır ve genellikle adreslerin tam olarak 20 bayt uzunluğunda olduğunu varsayan sıkı bayt-paketleme tekniklerini kullanır.@ipsilon/address-space-extension-exploration">Bunun çözümü için bir fikir, eski tarz sözleşmelerin yeni tarz adreslerle etkileşim kurduğu bir çeviri haritasıdır, bu durumda eski tarz adreslerin 20 baytlık bir yeni tarz adresin özetini görmesi gerekecektir. Bununla birlikte, bunu güvenli hale getirmek için önemli karmaşıklıklar bulunmaktadır.

Adres alanı daralması

Başka bir yaklaşım ise tam ters yönde ilerler: hemen 0xffffffff ile başlayan tüm adresleri içeren 2128 boyutlu alt aralığı yasaklarız ve ardından bu aralığı adres dönemleri ve 14 baytlık özetlerle tanıtırız.

0xfffffff000169125d5dFcb7B8C2659029395bdF

Bu yaklaşımın yaptığı temel fedakarlık, şudur ki,Karşı olgusal adresler için güvenlik riskleri oluşturur: varlıkları veya izinleri tutan ancak kodları henüz zincire yayınlanmamış olan adresler. Risk, birinin henüz yayınlanmamış bir kod parçasına sahip olduğunu iddia eden ancak aynı adrese karma yapmak için geçerli başka bir kod parçasına da sahip olan bir adres oluşturmasıyla ilgilidir. Böyle bir çarpışma hesaplamak için 2 gerektirir⁸⁰bugün hashlar; adres alanı daraltılması bu sayıyı çok erişilebilir bir 2'ye düşürür⁵⁶ hash'ler.

Anahtar risk alanı, tek bir sahibi tarafından tutulan cüzdanlar olmayan karşıt adreslerdir, bu bugün nispeten nadir bir durumdur, ancak çoklu L2 dünyasına girdiğimizde daha yaygın hale gelmesi muhtemeldir. Tek çözüm, bu riski basitçe kabul etmek, ancak bu durumun bir sorun olabileceği tüm ortak kullanım durumlarını belirlemek ve etkili çözümler bulmaktır.

Mevcut araştırmalara dair bazı bağlantılar nelerdir?

• Erken öneriler
  • Blockchain kira: https://github.com/ethereum/EIPs/issues/35
  • Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• Ethereum durum boyutu yönetimi teorisi:@vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
• Devletsizlik ve devletin süresi dolma olası birkaç olası yol: @vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
• Kısmi devlet sona erme önerileri
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• Adres alanı genişletme belgeleri
  • Orijinal teklif: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • Ipsilon incelemesi: @ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • Blog yazısı incelemesi: @chaisomsri96/devletsizlik-serisi-bolum2-ase-adres-alani-uzantisi-60626544b8e6"">https://medium.com/@chaisomsri96/devletsizlik-serisi-bolum2-ase-adres-alani-uzantisi-60626544b8e6
• Çarpışma direncini kaybedersek ne kırılır: https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

Yapılacak olan şeyler neler, ve hangi fedakarlıklar yapılacak?

Gelecek için dört uygulanabilir yol görüyorum:

• Biz devletsizlik yaparız ve asla devletin süresi dolmaz. Durum sürekli olarak büyüyor (ne kadar yavaş olursa olsun: onlarca yıl boyunca 8 TB'yi aşmasını görmeyebiliriz), ancak sadece nispeten uzmanlaşmış bir kullanıcı sınıfı tarafından tutulması gerekiyor: hatta PoS doğrulayıcıları bile devlete ihtiyaç duymaz.
  \
  Devletin bazı bölümlerine erişime ihtiyaç duyan tek işlev, dahil etme listesi üretimidir, ancak bunu merkezi olmayan bir şekilde başarabiliriz: her kullanıcı kendi hesaplarını içeren devlet ağacının bir bölümünü korumaktan sorumludur. Bir işlem yayınladıklarında, doğrulama adımı sırasında erişilen devlet nesnelerinin kanıtıyla birlikte yayınlarlar (bu, hem EOA'lar hem de ERC-4337 hesapları için çalışır). Devletsiz doğrulayıcılar daha sonra bu kanıtları tam dahil etme listesi için bir kanıt haline getirebilir.
• Kısmi durumun süresi dolmaz ve kalıcı durum boyutu büyümesinin çok daha düşük ancak hala sıfır olmayan bir oranını kabul ederiz. Bu sonuç, eşler arası ağları içeren geçmişin süresi dolma önerilerinin, her istemcinin düşük ancak sabit bir yüzdesini depolamak zorunda olduğu tarihsel verilerin düşük ancak hala sıfır olmayan bir oranını kabul ettiği şekilde tartışmasız benzer olabilir.
• Adres alanı genişletmesiyle birlikte durumun son kullanma tarihini belirliyoruz. Bu, mevcut uygulamalar için de geçerli olacak şekilde adres formatı dönüştürme yaklaşımının çalıştığından ve güvenli olduğundan emin olmak için çok yıllık bir süreci gerektirir.
• Adres alanı daraltma ile durum sona erecek. Bu, adres çakışmaları dahil olmak üzere, çapraz zincir durumlarını içeren tüm güvenlik risklerinin ele alınmasını sağlamak için çok yıllık bir süreci içerecektir.

Önemli bir nokta, adres alanı genişlemesi ve daralması etrafındaki zor konuların, adres formatı değişikliklerine bağlı durum süresi düzenlemelerine bağlı olup olmadığına bakılmaksızın, sonunda ele alınması gerekeceğidir. Bugün, yaklaşık 2⁸⁰bir adres çakışması oluşturmak için gereken karma sayısı, çok iyi kaynaklara sahip aktörler için zaten uygun olan bir hesaplama yüküdür: bir GPU yaklaşık olarak 2 yapabilir²⁷hash'ler, bu yüzden bir yıl boyunca çalıştığında 2 hesaplayabilir⁵², bu yüzden tüm ~2^30 dünyadaki GPU'laryaklaşık 1/4 yıl içinde bir çakışmayı hesaplayabilirdi ve FPGAs ve ASIC'ler bunu daha da hızlandırabilirdi. Gelecekte, böyle saldırılar giderek daha fazla insanın erişimine açık hale gelecektir. Bu nedenle, tam durum sona erme uygulamanın gerçek maliyeti, çok zorlu bu adres sorununu çözmek zorunda olduğumuz için göründüğü kadar yüksek olmayabilir.

Diğer yol haritası bölümleriyle nasıl etkileşime giriyor?

Devlet sona erme yapmak, bir devlet ağacı formatından başka birine geçişi kolaylaştırır, çünkü bir geçiş prosedürüne ihtiyaç olmayacak: yeni bir formatta yeni ağaçlar yapmaya başlayabilir ve daha sonra daha eski ağaçları dönüştürmek için sert bir çatal yapabilirsiniz. Bu nedenle, devlet sona erme karmaşık olsa da, yol haritasının diğer yönlerini basitleştirme konusunda faydaları vardır.

Özellik temizleme

Hangi sorunları çözüyor?

Güvenliğin, erişilebilirliğin ve güvenilir tarafsızlık basitliktir. Bir protokol güzel ve basitse, hata olma olasılığını azaltır. Yeni geliştiricilerin gelip herhangi bir bölümüyle çalışabilme şansını artırır. Özel çıkarlara karşı savunmanın adil ve daha kolay olması daha olasıdır. Ne yazık ki, protokoller, herhangi bir sosyal sistem gibi, varsayılan olarak zamanla daha karmaşık hale gelir. Ethereum'un sürekli artan karmaşıklığa sahip bir kara deliğe girmesini istemiyorsak, iki şeyden birini yapmamız gerekir: (i) değişiklik yapmayı bırakıp protokolü kemikleştirmek, (ii) özellikleri gerçekten kaldırabilmek ve karmaşıklığı azaltabilmek. Protokolde daha az değişiklik yapmak ve zaman içinde en azından biraz karmaşıklığı ortadan kaldırmak için bir ara yol da mümkündür. Bu bölüm, karmaşıklığı nasıl azaltabileceğimizi veya kaldırabileceğimizi konuşacaktır.

Bu nedir ve nasıl çalışır?

Protokol karmaşıklığını azaltabilecek büyük tek bir düzeltme yoktur; sorunun içsel doğası, birçok küçük düzeltmenin olmasıdır.

Zaten büyük ölçüde tamamlanmış olan ve diğerlerinin nasıl ele alınacağına dair bir mavi baskı olarak hizmet edebilecek bir örnek, @vbuterin/selfdestruct">SELFDESTRUCT opcode'unun kaldırılması. SELFDESTRUCT opcode, bir blok içinde sınırsız sayıda depolama yuvasını değiştirebilen tek opcode idi ve istemcilerin DoS saldırılarını önlemek için önemli ölçüde daha fazla karmaşıklık uygulamalarını gerektiriyordu. Orijinal amacı, gönüllü durum temizliğini etkinleştirmek ve zaman içinde durum boyutunu azaltmaktı. Uygulamada, bunu kullanan çok az kişi oldu. opcode zayıflatıldıDencun hardfork'ta yalnızca aynı işlemde oluşturulan kendini yok eden hesaplara izin vermek için değiştirildi. Bu, DoS sorununu çözer ve istemci kodunda önemli bir basitleştirmeye olanak tanır. Gelecekte, muhtemelen opkodu tamamen kaldırmak mantıklı olacaktır.

Şimdiye kadar tanımlanan protokol basitleştirme fırsatlarının bazı önemli örnekleri aşağıdakileri içerir. İlk olarak, EVM'nin dışında kalan bazı örnekler; Bunlar nispeten invaziv değildir ve bu nedenle daha kısa bir zaman diliminde fikir birliğine varmak ve uygulamak daha kolaydır.

• RLP → SSZ geçişi: Ethereum nesneleri aslen bir kodlama olan ile serileştirilmişti RLP. RLP türsüz ve gereksiz derecede karmaşıktır. Bugün, işaretçi zinciri kullanıyorSSZ (SSZ), birçok yönden daha iyi olan RLP'yi tamamen ortadan kaldırmak ve tüm veri tiplerini SSZ yapılarına dönüştürmek istiyoruz, bu da yükseltilebilirliği çok daha kolay hale getirecek. Bunun için mevcut EIP'ler şunları içerir,[1] [2] [3].
• Eski işlem türlerinin kaldırılması: Bugün çok sayıda işlem türü var ve bunlardan birçoğu potansiyel olarak kaldırılabilir. Tamamen kaldırmanın daha ılımlı bir alternatifi, akıllı hesapların, istedikleri takdirde eski stil işlemleri işlemek ve doğrulamak için kodu içerebileceği bir hesap soyutlama özelliğidir.
• LOG reform: günlükler, protokole karma filtreler ve diğer mantığı ekler, ancak çok yavaş olduğu için aslında istemciler tarafından kullanılmaz. bu özellikleri kaldırın, ve bunun yerine SNARK gibi modern teknoloji kullanan ek-protokol merkezi olmayan günlük okuma araçları gibi alternatiflere çaba gösterin.
• Beacon zinciri senkronizasyon komitesi mekanizmasının sonunda kaldırılması: eşzamanlama komitesi mekanizmasıbaşlangıçta Ethereum'un hafif istemci doğrulamasını etkinleştirmek için tanıtıldı. Ancak, protokole önemli bir karmaşıklık ekler. Sonunda, biz SNARK'ları kullanarak Ethereum konsensüs katmanını doğrudan doğrulayın, bu, özel bir hafif istemci doğrulama protokolüne gerek kalmadan yapılabilir. Potansiyel olarak, uzlaşının değiştirilmesi, bizi senkronizasyon komitelerini hatta daha erken kaldırabileceği, Ethereum uzlaşısı doğrulayıcılarının rastgele bir alt kümesinden imzaları doğrulamayı içeren daha 'doğal' bir hafif istemci protokolü oluşturarak.
• Veri formatı uyumlaştırma: bugün, yürütme durumu bir Merkle Patricia ağacında depolanır, uzlaşma durumu ise birSSZ ağacı, ve bloklar ile taahhüt edilir.@vbuterin/proto_danksharding_faq#Blob verileri hangi formatta ve nasıl taahhüt edilir">KZG taahhütlerinde kullanılan formattır. Gelecekte, blok verileri için tek bir birleşik bir format ve durum için tek bir birleşik bir format oluşturmak mantıklı olacaktır. Bu formatlar tüm önemli ihtiyaçları karşılar: (i) durumlu olmayan istemciler için kolay kanıtlar, (ii) veri için seri hale getirme ve silme kodlaması, (iii) standartlaştırılmış veri yapıları.
• Beacon zinciri komitelerinin kaldırılması: bu mekanizma başlangıçta desteklemek için tanıtıldı yürütme bölütleme özel bir versiyonu. Bunun yerine, sharding yapmaya karar verdik L2'ler ve bloklar aracılığıyla. Bu nedenle, komiteler gereksizdir ve böylece bir onları kaldırmaya doğru devam eden hareket.
• Karışık bit sırasının kaldırılması: EVM büyük uçlu ve işbirliği katmanı küçük uçludur. Her şeyi biri veya diğeri yapmak (muhtemelen EVM'nin değişmesi daha zor olduğu için büyük uçlu olmak) ve yeniden uyumlu hale getirmek mantıklı olabilir.

Şimdi, EVM içinde bulunan bazı örnekler:

• Gaz mekaniğinin basitleştirilmesi: mevcut gaz kuralları bir bloğun doğrulanması için gerekli olan kaynak miktarını net bir şekilde sınırlamak için yeterince iyi optimize edilmemiştir. Bunun için ana örnekler (i) depolama okuma/yazma maliyetleridir, bunlar bir blokta okuma/yazma sayısını sınırlamayı amaçlar, ancak şu anda oldukça rastgeledir, ve (ii) belleği doldurma kuralları, şu anda EVM'nin maksimum bellek tüketimini tahmin etmek zordur. Önerilen düzeltmelerdevletsizlik gaz maliyeti değişiklikleri, tüm depolama maliyetlerini basit bir formüle uyumlu hale getiren ve bu teklif bellek fiyatlandırması için.
• Precompiles'in kaldırılması: Ethereum'un bugün sahip olduğu birçok ön derleme hem gereksiz karmaşık hem de nispeten kullanılmamaktadır ve hiçbir uygulama tarafından kullanılmamaktadır. Bunu ele almanın iki yolu vardır: (i) sadece ön derlemeyi kaldırmak ve (ii) aynı mantığı uygulayan (kaçınılmaz olarak daha pahalı) bir EVM kod parçasıyla değiştirmek.Bu taslak EIP öneriyorBu, kimlik önceden derlemesini ilk adım olarak yapmak için yapılır; daha sonra, RIPEMD160, MODEXP ve BLAKE kaldırma adayları olabilir.
• Gaz gözlemi kaldırma: EVM yürütmesinin artık ne kadar gaz kaldığını görmemesini sağlayın. Bu, birkaç uygulamayı bozacaktır (özellikle sponsorlu işlemler), ancak gelecekte daha kolay bir şekilde yükseltmeyi mümkün kılacaktır (örneğin, daha gelişmiş sürümler için).çok boyutlu gaz). The EOF özellikEOF zaten gazı gözlemlemenin önüne geçiriyor, ancak protokol basitleştirilmesi için zorunlu hale gelmesi gerekiyor.
• Statik analizde iyileştirmeler: Bugün EVM kodunun statik olarak analiz edilmesi zordur, özellikle de sıçramaların dinamik olabileceği için. Bu aynı zamanda EVM kodunu başka bir dile önceden derleyen optimize edilmiş EVM uygulamalarını yapmayı da zorlaştırır. Bunun potansiyel olarak üstesinden gelebiliriz dinamik atlama işlemleri kaldırılıyor(veya onları çok daha pahalı hale getirerek, örn. bir sözleşmedeki toplam JUMPDEST sayısına lineer olarak gaz maliyeti artırmak). EOF bunu yapar, ancak bununla protokol basitleştirme kazançları elde etmek için EOF'u zorunlu hale getirmek gerekmektedir.

Mevcut araştırmalara ilişkin bazı bağlantılar nelerdir?

• Temizlikte Sonraki Adımlar: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• KENDİNİYOKET: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• SSZ-leştirme EIPS: [1] [2][3]
• Statelessness gaz maliyeti değişiklikleri: https://eips.ethereum.org/EIPS/eip-4762
• Lineer bellek fiyatlandırması: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Ön derleme kaldırma:https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Bloom filtre kaldırma: https://eips.ethereum.org/EIPS/eip-7668
• Artan doğrulanabilir hesaplama kullanarak off-chain güvenli günlük geri alma yapmanın bir yolu (okunabilir: tekrarlayan STARKs):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Yapılacak ne kaldı ve ne gibi fedakarlıklar yapılacak?

Bu tür özellik basitleştirmesini yaparken ana tercih şudur: (i) ne kadar basitleştirip ne kadar hızlı yapabiliriz ve (ii) geriye dönük uyumluluk. Ethereum'un değeri, bir uygulamayı dağıtabileceğiniz ve bundan yıllar sonra hala çalışacağından emin olabileceğiniz bir platform olmasından kaynaklanır. Aynı zamanda, bu idealizmi çok ileriye götürmek de mümkündür veWilliam Jennings Bryan'ın sözünü değiştirmek içinEthereum'ı geriye dönük uyumluluk haçında çarmıha germek. Ethereum'da belirli bir özelliği kullanan sadece iki uygulama varsa, biri yıllardır hiç kullanıcıya sahip değil ve diğeri neredeyse hiç kullanılmıyor ve toplamda 57 dolarlık bir değeri güvence altına alıyor, o zaman sadece özelliği kaldırmalı ve gerektiğinde mağdurlara cebimizden 57 dolar ödemeliyiz.

Daha geniş bir sosyal sorun, acil olmayan geriye dönük uyumsuzluk yaratan değişiklikler için standartlaştırılmış bir boru hattı oluşturmaktır. Bunun için bir yaklaşım, SELFDESTRUCT işlemi gibi mevcut örnekleri incelemek ve genişletmektir. Boru hattı aşağıdaki gibi görünmektedir:

• Adım 1: X özelliğini kaldırmaktan bahsetmeye başlayın
• Adım 2: Uygulamaların ne kadarının X'i kaldırmakla bozulduğunu belirlemek için analiz yapın, sonuçlara bağlı olarak ya (i) fikirden vazgeçin, (ii) planlandığı gibi devam edin veya (iii) X'i kaldırmak için değiştirilmiş bir 'en az müdahaleci' yol belirleyin ve onunla devam edin
• Adım 3: X'in kullanımını kaldırmak için resmi bir EIP oluşturun. Popüler yüksek seviye altyapıların (örneğin, programlama dilleri, cüzdanlar) bunu saygı göstermesini ve o özelliği kullanmayı bırakmasını sağlayın.
• Adım 4: sonunda, gerçekten X'i kaldırın

Adım 1 ile adım 4 arasında çok yıllık bir boru hattı olmalı, hangi öğelerin hangi adımda olduğu hakkında net bilgiler bulunmalı. O noktada, özellik kaldırma boru hattının ne kadar güçlü ve hızlı olduğu ile diğer protokol geliştirme alanlarına daha fazla kaynak koymak konusunda daha temkinli olma arasında bir denge bulunmaktadır, ancak hala Pareto sınırından uzaktayız.

EOF

EVM'ye önerilen önemli bir değişiklik seti, EVM Nesne Biçimi (EOF). EOF, gaz gözleminin yasaklanması, kod gözleminin (yani CODECOPY yok) ve yalnızca statik atlama izin verme gibi birçok değişiklik getiriyor. Hedef, EVM'nin daha güçlü özelliklere sahip bir şekilde yükseltilmesine izin verirken, geriye dönük uyumluluğu korumaktır (çünkü EOF öncesi EVM hala var olacaktır).

Bu, yeni EVM özelliklerini eklemek için doğal bir yol yaratması ve daha kısıtlayıcı, daha güçlü garanti sağlayan bir EVM'ye göçü teşvik etmesi avantajına sahiptir. Eski EVM'yi sonunda kullanımdan kaldırıp kaldıramayacağımızı bulamazsak, protokol karmaşıklığını önemli ölçüde artırır. Bir ana soru şudur: EVM basitleştirme önerilerinde EOF'un rolü nedir, özellikle EVM'nin genel karmaşıklığını azaltma hedefi varsa?

Diğer kısımlarla nasıl etkileşime geçiyor?

Yol haritasının geri kalanındaki "geliştirme" önerilerinin çoğu, eski özelliklerin basitleştirilmesi için fırsatlardır. Yukarıdaki örneklerden bazılarını tekrarlamak gerekirse:

• Tek yuvarlak bitişe geçmek, komiteleri kaldırma, ekonomiyi yeniden düzenleme ve diğer proof-of-stake ile ilgili basitleştirmeler yapma fırsatı verir.
• Hesap soyutlamasını tam olarak uygulamak, mevcut birçok işlem işleme mantığını kaldırmamızı sağlar, çünkü bunu tüm EOAs'ın yerine geçebilecek bir "varsayılan hesap EVM kodu" parçasına taşırız.
• Eğer Ethereum durumunu ikili kara ağaçlara taşırsak, bu, tüm Ethereum veri yapılarının aynı şekilde kara listelenebileceği yeni bir SSZ sürümüyle uyumlu hale getirilebilir.

Daha radikal bir yaklaşım: protokolün büyük bir kısmını sözleşme koduna dönüştürmek

Daha radikal bir Ethereum basitleştirme stratejisi, protokolü olduğu gibi tutmak ancak büyük bir bölümünü protokol özelliklerinden sözleşme koduna taşımaktır.

Bunun en uç versiyonu, Ethereum L1'i "teknik olarak" sadece işaret zinciri yapmak ve minimal bir VM (örn. RISC-V, Kahire, veya kanıt sistemleri için daha da minimal bir şekilde özelleştirilmiş bir şey) herhangi birinin kendi rollup'ını oluşturmasına izin veren bir protokol) dönüşebilir. EVM daha sonra bu rollup'ların ilki haline gelir. Bu, ilginç bir şekilde tam olarak aynı sonuç olur. 2019-20 yılından yürütme ortamı önerileri, ancak SNARK'lar bunu gerçekten uygulamak için önemli ölçüde daha uygun hale getiriyor.

Daha ılımlı bir yaklaşım, işaret zinciri ile mevcut Ethereum yürütme ortamı arasındaki ilişkiyi olduğu gibi tutmak, ancak EVM'nin yerinde takasını yapmak olacaktır. Yeni "resmi Ethereum VM'si" olarak RISC-V, Cairo veya başka bir VM'yi seçebilir ve ardından tüm EVM sözleşmelerini orijinal kodun mantığını yorumlayan (derleyerek veya yorumlayarak) yeni VM koduna zorla dönüştürebiliriz. Teorik olarak bu, EOF'nin bir sürümü olan "hedef VM" ile bile yapılabilir.

Feragatname：

1. Bu makale [den alıntılanmıştırVitalik Buterin], Tüm telif hakları orijinal yazarına aittir [Vitalik Buterin]. Bu yeniden basım konusunda itirazlarınız varsa, lütfen iletişime geçin.Gate Learnekip, ve bunu hızlı bir şekilde halledecekler.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüşler yalnızca yazarın kendi görüşleridir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri, gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.